SUSE-IU-2026:499-1
SUSE Image
security@suse.de
SUSE Security Team
SUSE Image SUSE-IU-2026:499-1
Interim
1
1
2026-03-19T09:01:50Z
current
2026-01-25T01:00:00Z
2026-01-25T01:00:00Z
cve-database/bin/generate-cvrf-publiccloud.pl
2021-02-18T01:00:00Z
Image update for SUSE-IU-2026:499-1 / google/sles-12-sp5-byos-v20260125-x86-64
This image update for google/sles-12-sp5-byos-v20260125-x86-64 contains the following changes:
Package polkit was updated:
- CVE-2025-7519: Fixed that a XML policy file with a large number of nested elements may lead to out-of-bounds write (bsc#1246472)
added 0001-Nested-.policy-files-cause-xml-parsing-overflow-lead.patch
Package openssl-1_1 was updated:
- Security fix: [bsc#1250232 CVE-2025-9230] * Fix out-of-bounds read & write in RFC 3211 KEK unwrap
* Add patch openssl3-CVE-2025-9230.patch
- Security fix: [bsc#1236136, CVE-2024-13176]
* timing side-channel in the ECDSA signature computation
* Add openssl-CVE-2024-13176.patch
- Security fix: [bsc#1220262, CVE-2023-50782]
* Implicit rejection in PKCS#1 v1.5
* Add openssl-CVE-2023-50782.patch
- Security fix: [bsc#1227138, CVE-2024-5535]
* SSL_select_next_proto buffer overread
* Add openssl-CVE-2024-5535.patch
- Apply "openssl-CVE-2024-4741.patch" to fix a use-after-free
security vulnerability. Calling the function SSL_free_buffers()
potentially caused memory to be accessed that was previously
freed in some situations and a malicious attacker could attempt
to engineer a stituation where this occurs to facilitate a
denial-of-service attack. [CVE-2024-4741, bsc#1225551]
- Security fix: [bsc#1222548, CVE-2024-2511]
* Fix unconstrained session cache growth in TLSv1.3
* Add openssl-CVE-2024-2511.patch
- Security fix: [bsc#1219243, CVE-2024-0727]
* Add NULL checks where ContentInfo data can be NULL
* Add openssl-CVE-2024-0727.patch
- Security fix: [bsc#1216922, CVE-2023-5678]
* Fix excessive time spent in DH check / generation with large Q
parameter value.
* Applications that use the functions DH_generate_key() to generate
an X9.42 DH key may experience long delays. Likewise,
applications that use DH_check_pub_key(), DH_check_pub_key_ex
() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42
DH parameters may experience long delays. Where the key or
parameters that are being checked have been obtained from an
untrusted source this may lead to a Denial of Service.
* Add openssl-CVE-2023-5678.patch
Package mozilla-nspr was updated:
- update to NSPR 4.36.2 * Fixed a syntax error in test file parsetm.c,
which was introduced in 4.36.1
- update to NSPR 4.36.1
* Incorrect time value produced by PR_ParseTimeString and
PR_ParseTimeStringToExplodedTime if input string doesn't
specify seconds.
- update to version 4.36
* remove support for OS/2
* remove support for Unixware, Bsdi, old AIX, old HPUX9 & scoos
* remove support for Windows 16 bit
* renamed the prwin16.h header to prwin.h
* configure was updated from 2.69 to 2.71
* various build, test and automation script fixes
* major parts of the source code were reformatted
Package 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])
- nscd-Fix-use-after-free-in-addgetnetgrentX.patch: nscd: Fix
use-after-free in addgetnetgrentX (BZ #23520)
- glibc-CVE-2024-33599-nscd-Stack-based-buffer-overflow-in-n.patch:
nscd: Stack-based buffer overflow in netgroup cache
(CVE-2024-33599, bsc#1223423, BZ #31677)
- glibc-CVE-2024-33600-nscd-Avoid-null-pointer-crashes-after.patch:
nscd: Avoid null pointer crashes after notfound response
(CVE-2024-33600, bsc#1223424, BZ #31678)
- glibc-CVE-2024-33600-nscd-Do-not-send-missing-not-found-re.patch:
nscd: Do not send missing not-found response in addgetnetgrentX
(CVE-2024-33600, bsc#1223424, BZ #31678)
- glibc-CVE-2024-33601-CVE-2024-33602-nscd-netgroup-Use-two.patch:
netgroup: Use two buffers in addgetnetgrentX (CVE-2024-33601,
CVE-2024-33602, bsc#1223425, BZ #31680)
- nscd-netgroup-cache-timeout.patch: Use time_t for return type of
addgetnetgrentX (CVE-2024-33602, bsc#1223425)
- elf-ifunc-subtests-nonpie.patch: elf: Disable some subtests of
ifuncmain1, ifuncmain5 for !PIE
- iconv-iso-2022-cn-ext.patch: iconv: ISO-2022-CN-EXT: fix out-of-bound
writes when writing escape sequence (CVE-2024-2961, bsc#1222992)
Package nfsidmap was updated:
- nss: use strrchr() instead of strchr() to get the last occurrence of "@" (bsc#1236077)
- add 0003-nss-use-strrchr-instead-of-strchr-to-get-the-last-oc.patch
Package yast2-registration was updated:
- Switch to the new SUSEConnect-ng (bsc#1212799), includes additional fixes:
- SSL reload fix (bsc#1195220)
- Detection of base products coming from SCC
(bsc#1194989, bsc#1217317)
- 3.3.2
Package glib2 was updated:
- Add glib2-CVE-2026-0988.patch: fix a potential integer overflow in g_buffered_input_stream_peek (bsc#1257049 CVE-2026-0988
glgo#GNOME/glib#3851).
- Add CVE fixes:
+ glib2-CVE-2025-13601.patch (bsc#1254297 CVE-2025-13601
glgo#GNOME/glib#3827).
+ glib2-CVE-2025-14087-1.patch, glib2-CVE-2025-14087-2.patch,
glib2-CVE-2025-14087-3.patch (bsc#1254662 CVE-2025-14087
glgo#GNOME/glib#3834).
+ glib2-CVE-2025-14512.patch (bsc#1254878 CVE-2025-14512
glgo#GNOME/glib#3845).
- Add glib2-CVE-2025-7039.patch: fix computation of temporary file
name (bsc#1249055 CVE-2025-7039 glgo#GNOME/glib#3716).
- Add glib2-CVE-2025-4373.patch: carefully handle gssize parameters
(bsc#1242844 CVE-2025-4373 glgo#GNOME/glib#3677).
- Add glib2-CVE-2024-52533.patch: fix a single byte buffer overflow
(boo#1233282 CVE-2024-52533 glgo#GNOME/glib#3461).
- Add glib2-gdbusmessage-cache-arg0.patch: cache the arg0 value in
a dbus message. Fixes a possible use after free (boo#1224044).
- Add patches to fix CVE-2024-34397 (boo#1224044):
glib2-CVE-2024-34397-add-ref-count-types.patch
glib2-allocate-SignalSubscriber-structs-individually.patch
glib2-CVE-2024-34397.patch (glgo#GNOME/glib#3268).
glib2-fix-ibus-regression.patch (glgo#GNOME/glib#3353)
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)
- 12.5.20241206 (tracked in bsc#933411)
- Added note about openJDK 11 support status (bsc#1233970)
- 12.5.20241014 (tracked in bsc#933411)
- Added note about openSSH 8.4 (bsc#1222298)
- Added note about unsupported hibernate/suspend on Xen (bsc#1214405)
- Added note about chrony 4.1 (jsc#SLE-22248)
- Added note about adcli --dont-expire-password (jsc#SLE-21223)
- Added note about sudo -U -l restriction (jsc#SLE-22569)
- Added note about nodejs16 addition (jsc#SLE-21234)
- Added note about rsyslog 8.2106 (jsc#SLE-21522)
- Added note about tcl 8.6.12 (jsc#SLE-21015)
- Added note about sudo 1.8.27 update (jsc#SLE-17083)
- Added note about unsupported modules (jsc#PED-8089)
- 12.5.20240614 (tracked in bsc#933411)
- Added note about openSSH 8.4 (bsc#1222298)
- Added note about unsupported hibernate/suspend on Xen (bsc#1214405)
- Added note about chrony 4.1 (jsc#SLE-22248)
- Added note about adcli --dont-expire-password (jsc#SLE-21223)
- Added note about sudo -U -l restriction (jsc#SLE-22569)
- Added note about nodejs16 addition (jsc#SLE-21234)
- Added note about rsyslog 8.2106 (jsc#SLE-21522)
- Added note about tcl 8.6.12 (jsc#SLE-21015)
- Added note about sudo 1.8.27 update (jsc#SLE-17083)
Package python-chardet was updated:
Package grub2 was updated:
- Fix CVE-2025-54771 (bsc#1252931) * 0001-kern-file-Call-grub_dl_unref-after-fs-fs_close.patch
- Fix CVE-2025-61662 (bsc#1252933)
* 0002-gettext-gettext-Unregister-gettext-command-on-module.patch
- Fix CVE-2025-61663 (bsc#1252934)
- Fix CVE-2025-61664 (bsc#1252935)
* 0003-normal-main-Unregister-commands-on-module-unload.patch
* 0004-tests-lib-functional_test-Unregister-commands-on-mod.patch
- Fix CVE-2025-61661 (bsc#1252932)
* 0005-commands-usbtest-Use-correct-string-length-field.patch
* 0006-commands-usbtest-Ensure-string-length-is-sufficient-.patch
- Bump upstream SBAT generation to 6
- Fix CVE-2024-56738: side-channel attack due to not constant-time
algorithm in grub_crypto_memcmp (bsc#1234959)
* grub2-constant-time-grub_crypto_memcmp.patch
- Fix page fault due to stricter memory permissions in shim 15.8 with later
ovmf built from edk2-stable202502 (bsc#1240771)
* 0001-efi-refactor-grub_efi_allocate_pages.patch
* 0002-Remove-grub_efi_allocate_pages.patch
* 0003-efi-change-heap-allocation-type-to-GRUB_EFI_LOADER_C.patch
* 0004-arm64-efi-move-EFI_PAGE-definitions-to-efi-memory.h.patch
* 0005-mkimage-Align-efi-sections-on-4k-boundary.patch
- 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
- Fix btrfs subvolume for platform modules not mounting at runtime when the
default subvolume is the topmost root tree (bsc#1228124)
* grub2-btrfs-06-subvol-mount.patch
- Rediff
* 0001-Unify-the-check-to-enable-btrfs-relative-path.patch
- Fix error in grub-install when linux root device is on lvm thin volume
(bsc#1192622) (bsc#1191974)
- Fix error in grub-install when root is on tmpfs (bsc#1226100)
* 0001-grub-install-bailout-root-device-probing.patch
- Make consistent check to enable relative path on btrfs (bsc#1174567) (bsc#1216912)
* 0001-Unify-the-check-to-enable-btrfs-relative-path.patch
Package zypper was updated:
- Show rpm install size before installing (bsc#1224771) If filesystem snapshots are taken before the installation (e.g.
by snapper) no disk space is freed by removing old packages. In
this case the install size of all packages is a hint how much
additional disk space is needed by the new packages static
content.
- version 1.13.67
- clean: Do not report an error if no repos are defined at all
(bsc#1223971)
- version 1.13.66
- Backport needs-rebooting command from Code15 (bsc#1217948)
- BuildRequires: libzypp-devel >= 16.22.11.
- version 1.13.65
Package libssh was updated:
- Security fix: [CVE-2025-8277, bsc#1249375] * Memory Exhaustion via Repeated Key Exchange
* Add patches:
- libssh-CVE-2025-8277-packet-Adjust-packet-filter-to-work-wh.patch
- libssh-CVE-2025-8277-Fix-memory-leak-of-unused-ephemeral-ke.patch
- libssh-CVE-2025-8277-ecdh-Free-previously-allocated-pubkeys.patch
- Security fix: [CVE-2025-8114, bsc#1246974]
* NULL pointer dereference when calculating session ID during KEX
* Add libssh-CVE-2025-8114.patch
- Fix CVE-2025-5318: Likely read beyond bounds in sftp server handle management (bsc#1245311)
* Add patch libssh-CVE-2025-5318.patch
- Fix CVE-2025-4877: Write beyond bounds in binary to base64 conversion functions (bsc#1245309)
* Add patch libssh-CVE-2025-4877.patch
- Fix CVE-2025-4878: Use of uninitialized variable in privatekey_from_file() (bsc#1245310)
* Add patches:
- libssh-CVE-2025-4878-1.patch
- libssh-CVE-2025-4878-2.patch
- Fix CVE-2025-5372: ssh_kdf() returns a success code on certain failures (bsc#1245314)
* Add patch libssh-CVE-2025-5372.patch
- Update to 0.9.8: [jsc#PED-7719, bsc#1218126, CVE-2023-48795]
* Rebase 0001-disable-timeout-test-on-slow-buildsystems.patch
* Remove patches fixed in the update:
- CVE-2019-14889.patch
- 0001-CVE-2020-1730-Fix-a-possible-segfault-when-zeroing-A.patch
- Update to version 0.9.8
* Fix CVE-2023-6004: Command injection using proxycommand (bsc#1218209)
* Fix CVE-2023-48795: Potential downgrade attack using strict kex (bsc#1218126)
* Fix CVE-2023-6918: Missing checks for return values of MD functions (bsc#1218186)
* Allow @ in usernames when parsing from URI composes
- Update to version 0.9.7
* Fix CVE-2023-1667: a NULL dereference during rekeying with algorithm
guessing (bsc#1211188)
* Fix CVE-2023-2283: a possible authorization bypass in
pki_verify_data_signature under low-memory conditions (bsc#1211190)
* Fix several memory leaks in GSSAPI handling code
- Update to version 0.9.6 (bsc#1189608, CVE-2021-3634)
* https://git.libssh.org/projects/libssh.git/tag/?h=libssh-0.9.6
- Add missing BR for openssh needed for tests
- update to 0.9.5 (bsc#1174713, CVE-2020-16135):
* CVE-2020-16135: Avoid null pointer dereference in sftpserver (T232)
* Improve handling of library initialization (T222)
* Fix parsing of subsecond times in SFTP (T219)
* Make the documentation reproducible
* Remove deprecated API usage in OpenSSL
* Fix regression of ssh_channel_poll_timeout() returning SSH_AGAIN
* Define version in one place (T226)
* Prevent invalid free when using different C runtimes than OpenSSL (T229)
* Compatibility improvements to testsuite
- Update to version 0.9.4
* https://www.libssh.org/2020/04/09/libssh-0-9-4-and-libssh-0-8-9-security-release/
* Fix possible Denial of Service attack when using AES-CTR-ciphers
CVE-2020-1730 (bsc#1168699)
Package sqlite3 was updated:
- Backpatch the URLs in sqlite3.n from https to http to avoid a file conflict with the tcl package on SLE-12.
- Sync version 3.50.2 from Factory:
* CVE-2025-6965, bsc#1246597:
Raise an error early if the number of aggregate terms in a
query exceeds the maximum number of columns, to avoid
downstream assertion faults.
* Add subpackage for the lemon parser generator.
+ sqlite-3.49.0-fix-lemon-missing-cflags.patch
+ sqlite-3.6.23-lemon-system-template.patch
- Sync version 3.49.1 from Factory (jsc#SLE-16032):
* CVE-2025-29087, CVE-2025-3277, bsc#1241020:
Fix a bug in the concat_ws() function, introduced in version
3.44.0, that could lead to a memory error if the separator
string is very large (hundreds of megabytes).
* CVE-2025-29088, bsc#1241078: Enhanced the
SQLITE_DBCONFIG_LOOKASIDE interface to make it more robust
against misuse.
* Obsoletes sqlite3-rtree-i686.patch
- Sync version 3.44.0 from Factory
* Fixes bsc#1210660, CVE-2023-2137: Heap buffer overflow
* sqlite3-rtree-i686.patch: temporary build fix for 32-bit x86.
* Obsoletes sqlite-CVE-2022-46908.patch
* Obsoletes sqlite-src-3390000-func7-pg-181.patch
Package libpcap was updated:
- Security fix: [bsc#1255765, CVE-2025-11961] * Fix out-of-bound-write and out-of-bound-read in pcap_ether_aton()
due to missing validation of provided MAC-48 address string
* Add libpcap-CVE-2025-11961.patch
- Security fix: [bsc#1230034, CVE-2024-8006]
* libpcap: NULL pointer derefence in pcap_findalldevs_ex()
* Add libpcap-CVE-2024-8006.patch
- Security fix: [bsc#1230020, CVE-2023-7256]
* libpcap: double free via addrinfo in sock_initaddress()
* Add libpcap-CVE-2023-7256.patch
Package openssh was updated:
- Add openssh-cve-2025-61984-username-validation.patch (bsc#1251198, CVE-2025-61984).
- Add openssh-bsc1232533-big-motd-failure.patch (bsc#1232533),
fixing failures with very large MOTDs. Thanks to Ali Abdallah
<ali.abdallah@suse.com>.
- 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
- also remember the active state of the service, so openssh8.4
can pick it up. bsc#1220110
- handle these when we do go from openssh8.4-server back to openssh
- remember the enabled state of sshd state, so openssh8,4 can pick it
up. bsc#1220110
- Added openssh-cve-2023-51385.patch (bsc#1218215, CVE-2023-51385).
This limits the use of shell metacharacters in host- and
user names.
- Added openssh-cve-2023-48795.patch (bsc#1217950, CVE-2023-48795).
This mitigates a prefix truncation attack that could be used to
undermine channel security.
Package systemd was updated:
- Apply coredump sysctl settings on systemd package updates/removals.- Add 6007-coredump-use-d-in-kernel-core-pattern.patch (bsc#1243935 CVE-2025-4598)
- Add the following patches (bsc#1241079 bsc#1241586)
6004-core-rename-queued_message-pending_reload_message.patch
6005-core-when-we-can-t-send-the-pending-reload-message-s.patch
6006-core-make-sure-we-don-t-throttle-change-signal-gener.patch-
- Import commit 866467ea64074193d226d09a3779c1ff0bec63b0
2aee6d7daf basic/hashmap: add cleanup of memory pools (#7164)
908ac43c61 core: add valgrind helper for daemon-reexec
5357cabb02 sd-bus: fix a memory leak in message_new_reply() (#7636)
db07d03e46 sd-bus: unify three code-paths which free struct bus_container
732f02acb0 bus-message: use structured initialization to avoid use of unitialized memory
- Add 6002-sd-bus-add-APIs-to-query-the-current-read-and-write-.patch and
6003-core-don-t-process-dbus-unit-and-job-queue-when-ther.patch (bsc#1231211 bsc#1231211)
- Don't try to restart the udev socket units anymore (bsc#1228809)
There's currently no way to restart a socket activable service and its socket
units "atomically" and safely.
- Add 6001-udev_monitor_receive_device-dynamically-allocate-rec.patch (bsc#1226095)
- Import commit 15ca9f01c18a8037bf26b1a85fee344c65944268
eedf77456d util: improve comments why we ignore EACCES and EPERM
2018a0d492 util: bind_remount_recursive_with_mountinfo(): ignore submounts which cannot be accessed
4c98cb57e2 namespace: don't fail on masked mounts (#3794) (bsc#1220285)
7dd5e84ab6 man: Document ranges for distributions config files and local config files
7282534592 Recommend drop-ins over modifications to the main config file
29e632c34a man: reword the description of "main conf file"
e903f529e8 man: rework section about configuration file precedence
4438e1be12 man: document paths under /usr/local in standard-conf.xml
- Import commit cdbaab11e02eb29810963d9248677cf5ce84dc7f
bf57bec240 man: document that PAMName= and NotifyAccess=all don't mix well.
823ec43d38 man: add brief documentation for the (sd-pam) processes created due to PAMName= (#4967)
256f8e70d2 service: accept the fact that the three xyz_good() functions return ints
2a62219d4d service: drop _pure_ decorator on static function
14e71b9180 service: a cgroup empty notification isn't reason enough to go down (bsc#1212207)
943f812b3d service: add explanatory comments to control_pid_good() and cgroup_good()
87a54d3060 service: fix main_pid_good() comment
- Import commit 17837e912c887402ff309215056d441b2881f9b6
27e9161566 utmp-wtmp: handle EINTR gracefully when waiting to write to tty
557ac78b1c utmp-wtmp: fix error in case isatty() fails
3e0bde3ade sd-netlink: handle EINTR from poll() gracefully, as success
61d939f79a stdio-bridge: don't be bothered with EINTR
367ee82375 sd-bus: handle -EINTR return from bus_poll() (bsc#1215241)
acca59ec26 libsystemd: ignore both EINTR and EAGAIN
0ae5743060 errno-util: introduce ERRNO_IS_TRANSIENT()
- Import commit f4af8cbfb8ddc2baddfd992ebff0fb4858e4f651
02dde27b0e man/systemd-fsck@.service: clarify passno and noauto combination in /etc/fstab (bsc#1211725)
9f0a3ab847 units/initrd-parse-etc.service: Conflict with emergency.target
98035f2aa8 umount: /usr/ should never be unmounted regardless of HAVE_SPLIT_USR or not (bsc#1211576)
0a8225faea core/mount: Don't unmount initramfs mounts
9eaf1537b4 man: describe that changing Storage= does not move existing data
Package freetype2 was updated:
- Added patch: * CVE-2025-23022.patch
+ fixes bsc#1235670, CVE-2025-23022: signed integer overflow in
cf2_doFlex in cff/cf2intrp.c
+ also fixes an overflow in cf2_hintmap_insertHint in
src/cff/cf2hints.c
+ it is a backport of upstream commits e66d7300 and 3802ca8b
- 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 ca-certificates-mozilla was updated:
- Fix awk to compare (missing a =) and give the following output: [#] NSS_BUILTINS_LIBRARY_VERSION "2.74"
- pass file argument to awk (bsc#1240009)
- update to 2.74 state of Mozilla SSL root CAs:
Removed:
* SwissSign Silver CA - G2
Added:
* D-TRUST BR Root CA 2 2023
* D-TRUST EV Root CA 2 2023
- remove extensive signature printing in comments of the cert
bundle
- Define two macros to break a build cycle with p11-kit.
- Updated to 2.72 state of Mozilla SSL root CAs (bsc#1234798)
Removed:
- SecureSign RootCA11
- Security Communication RootCA3
Added:
- TWCA CYBER Root CA
- TWCA Global Root CA G2
- SecureSign Root CA12
- SecureSign Root CA14
- SecureSign Root CA15
- Updated to 2.68 state of Mozilla SSL root CAs (bsc#1227525)
- Added: FIRMAPROFESIONAL CA ROOT-A WEB
- Distrust: GLOBALTRUST 2020
- Updated to 2.66 state of Mozilla SSL root CAs (bsc#1220356)
Added:
- CommScope Public Trust ECC Root-01
- CommScope Public Trust ECC Root-02
- CommScope Public Trust RSA Root-01
- CommScope Public Trust RSA Root-02
- D-Trust SBR Root CA 1 2022
- D-Trust SBR Root CA 2 2022
- Telekom Security SMIME ECC Root 2021
- Telekom Security SMIME RSA Root 2023
- Telekom Security TLS ECC Root 2020
- Telekom Security TLS RSA Root 2023
- TrustAsia Global Root CA G3
- TrustAsia Global Root CA G4
Removed:
- Autoridad de Certificacion Firmaprofesional CIF A62634068
- Chambers of Commerce Root - 2008
- Global Chambersign Root - 2008
- Security Communication Root CA
- Symantec Class 1 Public Primary Certification Authority - G6
- Symantec Class 2 Public Primary Certification Authority - G6
- TrustCor ECA-1
- TrustCor RootCert CA-1
- TrustCor RootCert CA-2
- VeriSign Class 1 Public Primary Certification Authority - G3
- VeriSign Class 2 Public Primary Certification Authority - G3
- remove-trustcor.patch: removed, now upstream
- do a versioned obsoletes of "openssl-certs".
Package google-osconfig-agent was updated:
- Update to version 20250416.02 (bsc#1244304, bsc#1244503) * defaultSleeper: tolerate 10% difference to reduce test flakiness (#810)
* Add output of some packagemanagers to the testdata (#808)
- from version 20250416.01
* Refactor OS Info package (#809)
- from version 20250416.00
* Report RPM inventory as YUM instead of empty SoftwarePackage
when neither Zypper nor YUM are installed. (#805)
- from version 20250414.00
* Update hash computation algorithm (#799)
- Update to version 20250320.00
* Bump github.com/envoyproxy/protoc-gen-validate from 1.1.0 to 1.2.1 (#797)
- from version 20250318.00
* Bump go.opentelemetry.io/otel/sdk/metric from 1.32.0 to 1.35.0 (#793)
- from version 20250317.02
* Bump cel.dev/expr from 0.18.0 to 0.22.0 (#792)
* Bump github.com/golang/glog from 1.2.3 to 1.2.4 in the go_modules group (#785)
- from version 20250317.01
* Bump cloud.google.com/go/logging from 1.12.0 to 1.13.0 (#774)
- from version 20250317.00
* Add tests for retryutil package. (#795)
- from version 20250306.00
* Update OWNERS (#794)
- from version 20250206.01
* Use separate counters for pre- and post-patch reboots. (#788)
- from version 20250206.00
* Update owners (#789)
- from version 20250203.00
* Fix the vet errors for contants in logging (#786)
- from version 20250122.00
* change available package check (#783)
- from version 20250121.00
* Fix Inventory reporting e2e tests. (#782)
- from version 20250120.00
* fix e2e tests (#781)
- Add -buildmode=pie to go build command line (bsc#1239948)
- Drop CVE-2024-45339.patch, merged upstream
- Renumber patches
- 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)
- Update to version 20240926.03 (bsc#1231775, bsc#1231776)
* Revert "Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)" (#684)
- from version 20240926.02
* Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)
* another batch of depencies upgrade (#683)
- from version 20240926.01
* aggregate dependabot changes to go.mod (#677)
* Revert back Source package info delivery to control-plane (#673)
- from version 20240926.00
* Update OWNERS (#676)
- from version 20240924.02
* Upgrade grpc and it's dependencies to latest version (#672)
- from version 20240924.01
* Implement keepalive config (#671)
- from version 20240924.00
* Set new version of gRPC for test (#669)
- from version 20240920.00
* Revert "bump version of the gRPC" (#667)
- from version 20240919.00
* bump version of the gRPC (#666)
- from version 20240917.00
* Merge pull request #665 from GoogleCloudPlatform/revert-664-update_grpc_dependency
* Revert "Update grpc library and other dependencies. (#664)"
- from version 20240916.00
* Update grpc library and other dependencies. (#664)
- from version 20240913.00
* Move packagebuild presubmit to osconfig (#662)
- from version 20240912.00
* Revert "update osconfig api to v1.13.0 & indirect dependency update" (#659)
- from version 20240822.00
* Revert "Source package info delivery to control-plane (#639)" (#656)
- from version 20240821.00
* Fix golang version format to fix builds. (#655)
- from version 20240814.01
* Use gcsfuse pkg in guest-policies e2e in pkg
update tests instead of old pkgs (#653)
* Replace osconfig-agent-test pkg by gcsfuse in ospolicies
tests and inventory-report tests (#652)
- from version 20240806.00
* Disable Repository Resource test for SLES-12 (#650)
- Update to version 20240801.00
* Fix Debian-12 failing test by using gcsfuse pkg
* Fix fetching gpg key unit tests (#649)
- from version 20240729.00
* Fix for old state file on Windows (#648)
- from version 20240723.00
* Add debugging logs for repository resource config (#646)
- from version 20240718.00
* Fix SLES-12 SP5 RPM package-resource e2e test (#645)
- from version 20240715.01
* Fix OSPolicies e2e tests for SLES-15 SP5 by removing
zypper update from VMs startup script (#644)
- from version 20240715.00
* Fix GuestPolicies e2e tests for SLES-15 SP5 by removing
zypper update from VMs startup script (#643)
- from version 20240709.01
* Source package info delivery to control-plane (#639)
- from version 20240709.00
* Enable gpgcheck flag for RPM e2e tests (#638)
- from version 20240708.00
* Update osconfig api to v1.13.0
* Indirect dependency update (#637)
- from version 20240705.01
* Updating Windows & Linux Chrome packages
to fix failing e2e tests (#636)
- from version 20240705.00
* Merge pull request #635 from Gulio/patch-1
* Update OWNERS
- from version 20240702.02
* Remove RHEL-7 and CentOS-7 images from e2e tests (#634)
- Update to version 20240702.01
* Use Debian-11 img in googet pkg build workflow (#632)
- from version 20240702.00
* Pipeline testing 00 (#631)
- from version 20240701.00
* update readme file (#628)
- from version 20240625.01
* Updating yum install to support multi architecture based packages
* Revert "Adding Architecture to the packages being installed/updated in yum repo"
- from version 20240625.00
* Update old SLES images urls (#627)
- from version 20240620.00
* Merge pull request #626 from GoogleCloudPlatform/yum-multiarch-fix
* Adding Architecture to the packages being installed/updated in yum repo
- from version 20240618.01
* Extract source_name(source_rpm) for rpm packages (#624)
- from version 20240618.00
* update README.md file (#625)
- from version 20240615.00
* Fix(dpkg) return onlt installed items as inventory (#623)
* Extract source name and version for dpkg packages. (#622)
- Update to version 20240607.00
* Update e2e tests to use VMM team's GCP project for pkgs testing version (#621)
- from version 20240606.00
* Disable SUSE tests to run with testing agent repo (#619)
- from version 20240604.00
* Fix the logic of pick region for Artifact Registry function (#618)
- from version 20240603.00
* Disable centos-stream-8 tests as it reached EOL in May 31 (#617)
- from version 20240529.00
* Merge pull request #610 from savijatv/patch-3
* Update cis-level1-once-a-day-policy.yaml
- from version 20240528.00
* Merge pull request #616 from MahmoudOuka/allow-windows-e2e-tests-to-\
install-testing-version-of-agent-from-private-artifact-registry-repos
* Allow Windows e2e tests to pull osconfig-agent pkg from testing (private)
repos from Artifact registry
- from version 20240527.01
* Merge pull request #615 from MahmoudOuka/fix-SUSE-e2e-tests
* fix SUSE e2e tests
- from version 20240527.00
* Merge pull request #614 from MahmoudOuka/allow-apt-and-yum-\
e2e-tests-to-pull-osconfig-agent-pkg-from-testing-repos
* fix golint comments
* Allow Apt & Yum e2e tests to pull osconfig-agent pkg from testing repos
- from version 20240524.03
* Merge pull request #611 from savijatv/patch-ospolicy-samples
* Update to the CIS OS policy samples
- from version 20240524.00
* Merge pull request #612 from MahmoudOuka/update-apt-e2e-tests-\
to-pull-osconfig-agent-pkg-from-new-ar-repos
* fix golint comment
* Update Apt e2e tests to pull osconfig-agent pkg from new AR repos instead of rapture
- from version 20240523.02
* bump golang.org/x/crypto version (#613)
- from version 20240523.00
* update go-cmp dependency (#604)
- from version 20240522.00
* rollback masive dependency update (#603)
* Bump google.golang.org/api from 0.180.0 to 0.181.0 (#596)
- Update to version 20240517.00
* Bump cloud.google.com/go/auth from 0.4.1 to 0.4.2 (#597)
- from version 20240516.01
* Bump cloud.google.com/go/logging from 1.9.0 to 1.10.0 (#595)
* Bump cloud.google.com/go/storage from 1.40.0 to 1.41.0 (#594)
- from version 20240516.00
* Bump google.golang.org/grpc from 1.63.2 to 1.64.0 (#593)
- Update to version 20240513.02
* E2e tests: allow passing spesific EL version
number to InstallOSConfigEL func (#592)
- from version 20240513.01
* Bump google.golang.org/api from 0.179.0 to 0.180.0 (#591)
- from version 20240513.00
* E2e tests: Fix EL version detection logic in E2E tests (#590)
* Bump google.golang.org/api from 0.178.0 to 0.179.0 (#589)
- from version 20240510.02
* Bump cloud.google.com/go/auth from 0.4.0 to 0.4.1 (#588)
- from version 20240510.01
* E2e tests: use family url format instead of specific
version URL for head test images (#587)
- from version 20240510.00
* Fix for lock location (#586)
- from version 20240509.03
* Bump cloud.google.com/go from 0.112.2 to 0.113.0 (#584)
- from version 20240509.02
* Remove dependabot not needed label (#576)
- from version 20240509.01
* Write inventory to attributes only if enabled (#486)
- from version 20240509.00
* E2e tests: install gnupg2 and run apt update in VMs startup-scripts (#583)
* Add a temporary e2e test image for Ubuntu to test
the latest osconfig-agent stable version (#582)
* Bump google.golang.org/api from 0.177.0 to 0.178.0 (#578)
* Bump github.com/googleapis/gax-go/v2 from 2.12.3 to 2.12.4 (#579)
* Bump cloud.google.com/go/iam from 1.1.7 to 1.1.8 (#577)
* Bump cloud.google.com/go/auth from 0.3.0 to 0.4.0 (#580)
* Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#581)
* Bump golang.org/x/net from 0.24.0 to 0.25.0 (#575)
* Bump cloud.google.com/go/osconfig from 1.12.6 to 1.12.7 (#573)
* Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#574)
* Bump cloud.google.com/go/longrunning from 0.5.6 to 0.5.7 (#571)
- from version 20240508.08
* Bump github.com/golang/glog from 1.2.0 to 1.2.1 (#572)
- from version 20240508.07
* Bump golang.org/x/text from 0.14.0 to 0.15.0 (#565)
- from version 20240508.06
* Bump golang.org/x/oauth2 from 0.19.0 to 0.20.0 (#566)
* Bump golang.org/x/sys from 0.19.0 to 0.20.0 (#564)
- from version 20240508.05
* Bump go.opentelemetry.io/otel/trace from 1.24.0 to 1.26.0 (#563)
- from version 20240508.04
* Bump google.golang.org/protobuf from 1.34.0 to 1.34.1 (#567)
* Using the default reviewer set for PR approvals (#570)
- from version 20240508.03
* Adding advanced CodeQL settings to scan on PRs (#569)
- from version 20240508.02
* Update Debian-12 package build workflow to use debian-cloud project (#568)
- from version 20240508.01
* Dependabot dependency updates (#562)
- from version 20240508.00
* Revert "Initial configuration of the dependabot
for the direct and indirect dâ¦" (#561)
* Initial configuration of the dependabot for the
direct and indirect dependency scanning (#560)
- from version 20240507.00
* Fix Debian-12 package build workflow typo (#559)
- from version 20240506.00
* Use signed-by keyring approach for apt repos in Debian 12+ and Ubuntu 24+ (#558)
- from version 20240501.03
* Logrus dependency update (#557)
- from version 20240501.02
* Updating dependencies and respective checksums (#556)
- from version 20240501.01
* Update go.mod (#554)
- from version 20240501.00
* Bump golang.org/x/net from 0.17.0 to 0.23.0 (#542)
- from version 20240430.01
* Remove SBOM generation logic from package build workflows (#553)
- from version 20240425.00
* Fix e2e tests for exec-output size limit (#552)
- from version 20240424.00
* Disabled some images which are either past EoL or broken (#549)
- from version 20240423.01
* Copy packagebuild folder from guest-test-infra repo to osconfig repo (#545)
* OS Config windows state file location changed (#544)
- from version 20240423.00
* Removed debian-10 from e2e tests (#548)
- from version 20240422.00
* Merge pull request #541 from GoogleCloudPlatform/michaljankowiak-patch-1
* Update OWNERS
- from version 20240409.00
* Bump output size limit to 500KB (#538)
- Update to version 20240320.00 (bsc#1221900, bsc#1221901)
* Enable OSConfig agent to read GPG keys files with multiple entities (#537)
- from version 20240314.00
* Update OWNERS file to replace mahmoudn GitHub
username by personal email GitHub username (#534)
- from version 20240313.01
* Bump google.golang.org/protobuf from 1.30.0 to 1.33.0 in /e2e_tests (#535)
- from version 20240313.00
* Adds a console and gcloud example policies (#533)
- from version 20240228.00
* GuestPolicies e2e: Remove ed package if exist for zypper
startup_script in recipe-steps tests (#532)
- from version 20240126.00
* Fix Enterprise Linux Recipe-Steps tests to install
info dependency package in the startup-script (#530)
- from version 20240125.01
* Fix SUSE pkg-update and pkg-no-update e2e tests (#529)
- from version 20240125.00
* Fix zypper patch info parser to consider conflicts-pkgs float versions (#528)
- from version 20240123.01
* Fix SUSE package update e2e tests to use another existing package (#527)
- from version 20240123.00
* Update cis-exclude-check-once-a-day.yaml (#526)
- Update to version 20231219.00
* Bump golang.org/x/crypto from 0.14.0 to 0.17.0 (#524)
- from version 20231207.01
* Some change to create an agent release (#523)
- from version 20231207.00
* Some change to create an agent release (#522)
- from version 20231205.00
* Some change to create an agent release (#521)
- from version 20231130.02
* Merge pull request #519 from Gulio/just-release
* Merge branch 'master' into just-release
* Some change to create an agent release
* Some change to create an agent release
- from version 20231130.00
* Some change to create an agent release (#518)
- from version 20231129.00
* Fix parse yum updates to consider the packages under
installing-dependencies keyword (#502)
* Update feature names in the README file (#517)
- from version 20231128.00
* Updating owners (#508)
- from version 20231127.00
* Move OS policy CIS examples under the console folder (#514)
- from version 20231123.01
* Adds three more OS Policy examples to CIS folder (#509)
* Added ekrementeskii and MahmoudNada0 to OWNERS (#505)
- from version 20231123.00
* docs(osconfig):add OS policy examples for CIS scanning (#503)
- from version 20231121.02
* Added SCODE to Windows error description (#504)
- from version 20231121.01
* Update OWNERS (#501)
* Update go version to 1.21 (#507)
- from version 20231121.00
* Call fqdn (#481)
- from version 20231116.00
* Removing obsolete MS Windows 2019 images (#500)
- from version 20231107.00
* Update owners. (#498)
- from version 20231103.02
* Increasing test timeouts (#499)
* Update OWNERS (#497)
- from version 20231103.01
* Bump google.golang.org/grpc from 1.53.0 to 1.56.3 in /e2e_tests (#493)
* Bump google.golang.org/grpc from 1.53.0 to 1.56.3 (#494)
- from version 20231103.00
* Removing deprecated Win for containers OSs (#496)
- from version 20231027.00
* Shortening the reported image names (#495)
- from version 20231025.00
* Merge pull request #492 from GoogleCloudPlatform/michaljankowiak-patch-1
* Merge branch 'master' into michaljankowiak-patch-1
* Fixing name changes
* Fixing rename issue
* Fixed formatting
* Fixed formatting
* Fixing formatting
* Removing support for RHEL 6, adding RHEL 9
* Removing support for RHEL 6, adding for RHEL 9
* Removing support for RHEL 6 and adding for RHEL 9
* Removing step needed for RHEL 6
* Fixing build issues
* Removing nonexistent images and adding new ones
- from version 20231024.00
* Removing obsolete OS images and adding new ones (#491)
- from version 20231020.00
* Change debug messages when parsing zypper patch output (#490)
- from version 20231013.00
* Bump golang.org/x/net from 0.7.0 to 0.17.0 (#489)
- from version 20231010.00
* Revert "Added [main] section with gpgcheck to
the agent-managed repo file (#484)" (#488)
- from version 20231003.00
* Bump google.golang.org/grpc from 1.42.0 to 1.53.0 in /e2e_tests (#478)
- from version 20230920.00
* Update OWNERS (#485)
- from version 20230912.00
* Added [main] section with gpgcheck to the agent-managed repo file (#484)
* Migrate empty interface to any (#483)
- Bump the golang compiler version to 1.21 (bsc#1216546)
- Update to version 20230829.00
* Added burov, dowgird, paulinakania and Gulio to OWNERS (#482)
Package libxslt was updated:
- security update- added patches
CVE-2025-11731 [bsc#1251979], type confusion in exsltFuncResultCompfunction leading to denial of service
* libxslt-CVE-2025-11731.patch
- propagate test failure into build failure
- added sources
* libxslt-test-results.ref
- Security fixes:
* Fix use-after-free of XPath context node [bsc#1239625, CVE-2025-24855]
* Fix UAF related to excluded namespaces [bsc#1239637, CVE-2024-55549]
* Add patches:
- libxslt-CVE-2024-55549.patch
- libxslt-CVE-2025-24855.patch
Package bash was updated:
- Add patch bsc1245199.patch * Fix histfile missing timestamp for the oldest record (bsc#1245199)
Package fdupes was updated:
- Apply "toctou-race-allows-arbitrary-file-deletion.patch" to fix a race condition that could be exploited to delete arbitrary files.
This patch is a back-ported and simplified version of the commit
https://github.com/adrianlopezroche/fdupes/commit/85680897148f1ac33b55418e00334116e419717f
introduced upstream in release 2.2.0. [bsc#1200381]
Package nghttp2 was updated:
- security update- added patches
fix CVE-2024-28182 [bsc#1221399], HTTP/2 CONTINUATION frames can be utilized for DoS attacks
+ nghttp2-CVE-2024-28182-1.patch
fix CVE-2024-28182-2 [bsc#1221399], HTTP/2 CONTINUATION frames can be utilized for DoS attacks
+ nghttp2-CVE-2024-28182-2.patch
- security update
- added patches
fix CVE-2023-44487 [bsc#1216123], HTTP/2 Rapid Reset Attack
+ nghttp2-CVE-2023-44487.patch
Package python-setuptools was updated:
- Add patch CVE-2025-47273.patch to fix A path traversal vulnerability.
(bsc#1243313, CVE-2025-47273, gh#pypa/setuptools@250a6d17978f)
- Add patch CVE-2024-6345-code-execution-via-download-funcs.patch:
* Sanitize any VCS URL we download. (CVE-2024-6345, bsc#1228105)
Package less was updated:
- Fix CVE-2024-32487, mishandling of \n character in paths when LESSOPEN is set leads to OS command execution
(CVE-2024-32487, bsc#1222849)
* CVE-2024-32487.patch
- Fix CVE-2022-48624, LESSCLOSE handling in less does not quote shell
metacharacters, bsc#1219901
* CVE-2022-48624.patch
Package ksh was updated:
- do not use posix_spawn as it lacks proper job handling [bsc#1224057] new patch: ksh93-no-posix_spawn.dif
- fix segfault in variable substitution [bsc#1129288]
new patch: ksh93-putval.dif
- fix untrusted environment execution [bsc#1160796] [CVE-2019-14868]
new patch: ksh93-untrustedenv.dif
Package xfsprogs was updated:
- libfrog: fix missing error checking in workqueue code (bsc#1227232) - add xfsprogs-libfrog-fix-missing-error-checking-in-workqueue-code.patch
- xfs_repair: ignore empty xattr leaf blocks (bsc#1227911)
- add xfsprogs-xfs_repair-ignore-empty-xattr-leaf-blocks.patch
- mkfs: terminate getsubopt arrays properly (bsc#1228270)
- add xfsprogs-mkfs-terminate-getsubopt-arrays-properly.patch
- xfs_copy: bail out early when superblock cannot be verified
(bsc#1227150)
- fix return value of error code, which is expected to be negative
- xfs_copy: bail out early when superblock cannot be verified
(bsc#1227150)
- add xfs_copy-bail-out-early-when-superblock-cannot-be-ve.patch
Package nfs-utils was updated:
- Add 0208-mountd-add-support-for-case-insensitive-file-names.patch Fix for bsc#1221774 - support case-insensivtive file names
- Add 0207-exportfs-Ingnore-export-failures-in-nfs-server.seriv.patch
Inconsistencies in /etc/exports shouldn't be fatal.
(bsc#1212594)
Package google-guest-configs was updated:
- Check that %{_sysconfdir}/sysconfig/network/ifcfg-eth0 actually exists before making any modifications to it (bsc#1241112)
- 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="compat:suse:google_up.sh"
to /etc/sysconfig/network/ifcfg-eth0 in %post and %postun sections
- Update to version 20241121.00 (bsc#1233625, bsc#1233626)
* Temporarily revert google_set_multiqueue changes for release (#92)
- from version 20241115.00
* Remove IDPF devices from renaming rules (#91)
- from version 20241112.00
* Revert "Revert 3 commits:" (#89)
- from version 20241108.00
* Revert 3 commits: (#87)
- from version 20241107.00
* gce-nic-naming: Exit 1 so that udev ignores the rule on error (#86)
- from version 20241106.00
* Remove Apt IPv4 only config for Debian and Ubuntu (#85)
- from version 20241031.00
* Add GCE intent based NIC naming tools (#84)
- from version 20241025.00
* Update google_set_multiqueue to skip set_irq
if NIC is not a gvnic device (#83)
- Add new binary gce-nic-naming to %{_bindir} in %files section
- Update to version 20241021.00 (bsc#1231775, bsc#1231776)
* Add GCE-specific config for systemd-resolved (#82)
- from version 20241015.00
* Update google_set_multiqueue to enable on A3Ultra family (#79)
- from version 20241013.00
* Update OWNERS (#81)
- from version 20241010.00
* Depend on jq in enterprise linux (#80)
- from version 20241008.00
* Always use IP from primary NIC in the
networkd-dispatcher routable hook (#78)
- Update to version 20240925.00
* Call google_set_hostname on openSUSE and when the agent
is configured to manage hostname and FQDN, let it (#75)
- from version 20240924.00
* Include systemd-networkd hook in Ubuntu packaging (#77)
- from version 20240905.00
* Update packaging as of Ubuntu devel packaging (#65)
- from version 20240830.00
* Fix the name for A3 Edge VMs (#76)
- Update to version 20240725.00
* Fix: hostnamectl command (#74)
- Update to version 20240607.00
* Update is_a3_platform to include A3-edge shape (#73)
- Update to version 20240514.00
* Add systemd-networkd hostname hook (#71)
- from version 20240501.00
* Add hostname hook for NetworkManager without
dhclient compat script (#70)
- Update to version 20240307.00 (bsc#1221146, bsc#1221900, bsc#1221901)
* Support dot in NVMe device ids (#68)
- from version 20240304.00
* google_set_hostname: Extract rsyslog service name
with a regexp for valid systemd unit names (#67)
- from version 20240228.00
* Remove quintonamore from OWNERS (#64)
- from version 20240119.00
* Setup smp affinity for IRQs and XPS on A3+ VMs (#63)
- Update to version 20231214.00
* set multiqueue: A3 check set timeout the MDS call in 1s (#62)
- from version 20231103.00
* Update owners (#61)
* Update owners (#58)
- Update to version 20230929.00
* Update multinic filter to pick only pci devices (#59)
Package suse-build-key was updated:
- add and run a import-suse-build-key script, which will be run after installation using a systemd timer. (jsc#PED-2777)
- extended 2048 bit SUSE SLE 12, 15 GA-SP5 key until 2028. (bsc#1229339)
- gpg-pubkey-39db7c82-5f68629b.asc
+ gpg-pubkey-39db7c82-66c5d91a.asc
Package python-typing was updated:
- Update to 3.10.0.0 * Implement TypeGuard (PEP 649)
* backport ParamSpecArgs/Kwargs
* Fixed required/optional keys with old-style TypedDict
* Bring in protocolâs __init__ behaviour same like in python > 3.8
* Support PEP 612 in typing_extensions (Python 3)
* Also run python 3.9 in CI
* Add OrderedDict to typing_extensions
* Only allow installing this package for Python 2.7 and 3.4
* Document availability of Annotated
* Update test_typing_extensions.py
* Apply get_args fix from bpo-40398 to typing_extensions
* Fix tests failing with 3.10.0a2+
* Fix stray close paren
* Update README
* Disable 3.5.1 build -- can't install psutils needed by pytest-xdist
* Bump typing_extensions version to 3.7.4.3
* Remove extra 'use' in readme
- from version 3.7.4.3
* Revert last two changes; bump version to 3.7.4.3
- from version 3.7.4.2
* Disallow installation on 3.5+
* Add tox.ini for typing_extensions
* Add PEP 613 TypeAlias to typing_extensions
* Make tests for Annotated work with Python 3.9
* Remove Python 3.3 from tox.ini
* Fix flake8 failure by using Python 3.8
* Add SupportsIndex, added in Python 3.8
* Update package metadata
* Bump typing_extensions version to 3.7.4.2
* Fix ForwardRef hash and equality checks
* Fix required and optional keys inheritance for TypedDict
* Replace asyncio.coroutine with async-await
* Reuse stdlib PEP 593 implementation in typing_extensions if present
* Add .vscode and .egg-info to gitignore
* Backport get_origin() and get_args()
* Add clarification to package description
* Track optional TypdeDict keys
* Accept arbitrary keyword names in NamedTuple() and TypedDict()
* Bump typing_extensions version
* Add missing objects in typing_extensions/README.rst
- from version 3.7.4.1
* Fix isinstance() with generic protocol subclasses after subscripting
* Try fixing Travis build
+ fix tests for non-default interpreters
* Use environment marker to specify typing dependency
* Fix unions of protocols on Python 2
* Bump typing_extensions version and typing dependency version
- from version 3.7.4
* Fix subclassing builtin protocols on older Python versions
* Move Protocol, runtime_checkable, Final, final, Literal, and TypedDict to typing
* Add support for Python 3.8 in typing_extensions
* Unify the implementation of annotated in src_py2 and src_py3
* Add Annotated in python2
* Pep 593 py3
* Drop support of Python 3.3
* [typing-extensions] Simple implementation for IntVar
* Add a python 3.7+ version of Annotated to typing_extensions
* Add SupportsIndex
* Add TypedDict to typing_extensions
* .travis.yml: The 'sudo' tag is now deprecated in Travis CI
* Add Final to the README
* Run the tests using the current Python executable
* Fix GeneralMeta.__instancecheck__() for old style classes
* Bump typing_extensions version
* Add Literal[...] types to typing_extensions
* Fix instance/subclass checks of functions against runtime protocols
* Bump typing_extension version
* Improve PyPI entry for typing_extensions
* Add Final to typing_extensions
- from version 3.6.6
* Include license file for typing-extensions and in wheels
* Fix IO.closed to be property
* Backport Generic.__new__ fix
* Bump typing_extensions version before release
* Add missing 'NoReturn' to __all__ in typing.py
* Add annotations to NamedTuple children __new__ constructors
* Fix typing_extensions to support PEP 560
* Fix for issue #524
* Pass *args and **kwargs to superclass in Generic.__new__
- Rename README.rst to README.md in %doc section
Package samba was updated:
- CVE-2025-9640: fix vfs_streams_xattr uninitialized memory write; (bsc#1251279);(bso#15885).
- CVE-2025-10230: fix command Injection in WINS Server Hook Script;
(bsc#1251280);(bso#15903).
- Windows security hardening locks out schannel'ed netlogon dc
calls like netr_DsRGetDCName; (bsc#1246431); (bso#15876).
- Update shipped /etc/samba/smb.conf to point to smb.conf
man page;(bsc#1233880).
- Add new idmap_nss option 'use_upn' for those NSS modules able to
handle UPNs or DOMAIN/user name format; (bsc#1215369);
- Avoid unnecessary locking in idmap parent setup; (bsc#1215369);
- Do not try to set domain online in the idmap child;
(bsc#1215369); (bso#15317).
Package openssl-1_0_0 was updated:
- Security fix: [bsc#1250232 CVE-2025-9230] * Fix out-of-bounds read & write in RFC 3211 KEK unwrap
* Add patch openssl3-CVE-2025-9230.patch
- Pull libopenssl-1_0_0 when updating openssl-1_0_0 with the same
version. [bsc#1228291]
- Security fix: [bsc#1227138, bsc#1227227, CVE-2024-5535]
* SSL_select_next_proto buffer overread
* Add openssl-CVE-2024-5535.patch
- Security fix: [bsc#1219243, CVE-2024-0727]
* Add NULL checks where ContentInfo data can be NULL
* Add openssl-CVE-2024-0727.patch
- Security fix: [bsc#1216922, CVE-2023-5678]
* Fix excessive time spent in DH check / generation with large Q
parameter value.
* Applications that use the functions DH_generate_key() to generate
an X9.42 DH key may experience long delays. Likewise,
applications that use DH_check_pub_key(), DH_check_pub_key_ex
() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42
DH parameters may experience long delays. Where the key or
parameters that are being checked have been obtained from an
untrusted source this may lead to a Denial of Service.
* Add openssl-CVE-2023-5678.patch
Package cloud-netconfig was updated:
- Update to version 1.14 + Use '-s' instead of '--no-progress-meter' for curl (bsc#1221757)
- Add version settings to Provides/Obsoletes
- Update to version 1.12 (bsc#1221202)
+ If token access succeeds using IPv4 do not use the IPv6 endpoint
only use the IPv6 IMDS endpoint if IPv4 access fails.
- Add Provides/Obsoletes for dropped cloud-netconfig-nm
- Install dispatcher script into /etc/NetworkManager/dispatcher.d
on older distributions
- Add BuildReqires: NetworkManager to avoid owning dispatcher.d
parent directory
- Update to version 1.11:
+ Revert address metadata lookup in GCE to local lookup (bsc#1219454)
+ Fix hang on warning log messages
+ Check whether getting IPv4 addresses from metadata failed and abort
if true
+ Only delete policy rules if they exist
+ Skip adding/removing IPv4 ranges if metdata lookup failed
+ Improve error handling and logging in Azure
+ Set SCRIPTDIR when installing netconfig wrapper
- Update to version 1.10:
+ Drop cloud-netconfig-nm sub package and include NM dispatcher
script in main packages (bsc#1219007)
+ Spec file cleanup
- Update to version 1.9:
+ Drop package dependency on sysconfig-netconfig
+ Improve log level handling
+ Support IPv6 IMDS endpoint in EC2 (bsc#1218069)
Package python-idna was updated:
- Add CVE-2024-3651.patch, backported from upstream commit gh#kjd/idna#172/commits/5beb28b9dd77912c0dd656d8b0fdba3eb80222e7
(bsc#1222842, CVE-2024-3651)
Package supportutils-plugin-suse-public-cloud was updated:
- Update to version 1.0.9 (bsc#1218762, bsc#1218763) + Remove duplicate data collection for the plugin itself
+ Collect archive metering data when available
+ Query billing flavor status
Package tar was updated:
- Fix CVE-2023-39804, Incorrectly handled extension attributes in PAX archives can lead to a crash, bsc#1217969
* fix-CVE-2023-39804.patch
Package autofs was updated:
- autofs-5.1.8-dont-use-initgroups-at-spawn.patch Don't use initgroups at spawn (bsc#1214710)
Package coreutils was updated:
- coreutils-9.7-sort-CVE-2025-5278.patch: Add upstream patch: sort with key character offsets of SIZE_MAX, could induce
a read of 1 byte before an allocated heap buffer.
(CVE-2025-5278, bsc#1243767)
Package python36 was updated:
- Add CVE-2025-13836-http-resp-cont-len.patch (bsc#1254400, CVE-2025-13836) to prevent reading an HTTP response from
a server, if no read amount is specified, with using
Content-Length per default as the length.
- Add CVE-2025-12084-minidom-quad-search.patch prevent quadratic
behavior in node ID cache clearing (CVE-2025-12084,
bsc#1254997).
- Add CVE-2025-13837-plistlib-mailicious-length.patch protect
against OOM when loading malicious content (CVE-2025-13837,
bsc#1254401).
- Add CVE-2025-6075-expandvars-perf-degrad.patch avoid simple
quadratic complexity vulnerabilities of os.path.expandvars()
(CVE-2025-6075, bsc#1252974).
- Skip test_curses on ppc64le (gh#python/cpython#141534)
- Add CVE-2025-8291-consistency-zip64.patch which checks
consistency of the zip64 end of central directory record, and
preventing obfuscation of the payload, i.e., you scanning for
malicious content in a ZIP file with one ZIP parser (let's say
a Rust one) then unpack it in production with another (e.g.,
the Python one) and get malicious content that the other parser
did not see (CVE-2025-8291, bsc#1251305)
- Readjust patches while synchronizing between openSUSE and SLE trees:
- F00251-change-user-install-location.patch
- doc-py38-to-py36.patch
- gh126985-mv-pyvenv.cfg2getpath.patch
- Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now
validates archives to ensure member offsets are non-negative
(gh#python/cpython#130577, CVE-2025-8194, bsc#1247249).
- Add CVE-2025-4435-normalize-lnk-trgts-tarfile.patch
Security fixes for CVE-2025-4517, CVE-2025-4330, CVE-2025-4138,
CVE-2024-12718, CVE-2025-4435 on tarfile (bsc#1244032,
bsc#1244061, bsc#1244059, bsc#1244060, bsc#1244056).
The backported fixes do not contain changes for ntpath.py and
related tests, because the support for symlinks and junctions
were added later in Python 3.9, and it does not make sense to
backport them to 3.6 here.
The patch is contains the following changes:
- python@42deeab fixes symlink handling for tarfile.data_filter
- python@9d2c2a8 fixes handling of existing files/symlinks in tarfile
- python@00af979 adds a new "strict" argument to realpath()
- python@dd8f187 fixes mulriple CVE fixes in the tarfile module
- downstream only fixes that makes the changes work and
compatible with Python 3.6
- Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst
case quadratic complexity when processing certain crafted
malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705).
- Add python36-* provides/obsoletes to enable SLE-12 -> SLE-15
migration, bsc#1233012
- Add ipaddress-update-pr60.patch from gh#phihag/ipaddress!60 to
update vendored ipaddress module to 3.8 equivalent
- Add gh-128840_parse-IPv6-with-emb-IPv4.patch to limit buffer
size for IPv6 address parsing (gh#python/cpython#128840,
bsc#1244401).
- Update CVE-2025-4516-DecodeError-handler.patch not to break
_PyBytes_DecodeEscape signature.
- Add CVE-2025-4516-DecodeError-handler.patch fixing
CVE-2025-4516 (bsc#1243273) blocking DecodeError handling
vulnerability, which could lead to DoS.
- Update CVE-2024-11168-validation-IPv6-addrs.patch
according to the Debian version
(gh#python/cpython#103848#issuecomment-2708135083).
- 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)
- Remove -IVendor/ from python-config boo#1231795
- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1
- Add CVE-2024-11168-validation-IPv6-addrs.patch
fixing bsc#1233307 (CVE-2024-11168,
gh#python/cpython#103848): Improper validation of IPv6 and
IPvFuture addresses.
- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
path names provided when creating a virtual environment
(bsc#1232241, CVE-2024-9287)
- Drop .pyc files from docdir for reproducible builds
(bsc#1230906).
- Add CVE-2024-6232-ReDOS-backtrack-tarfile.patch prevent
ReDos via excessive backtracking while parsing header values
(bsc#1230227, CVE-2024-6232).
- Add CVE-2024-5642-switch-off-NPN.patch switching off the NPN
support eliminating bsc#1227233 (CVE-2024-5642).
- Add CVE-2024-6923-email-hdr-inject.patch to prevent email
header injection due to unquoted newlines (bsc#1228780,
CVE-2024-6923).
- Add CVE-2024-7592-quad-complex-cookies.patch fixing quadratic
complexity in parsing cookies with backslashes (bsc#1229596,
CVE-2024-7592)
- %{profileopt} variable is set according to the variable
%{do_profiling} (bsc#1227999)
- Remove %suse_update_desktop_file macro as it is not useful any
more.
- Stop using %%defattr, it seems to be breaking proper executable
attributes on /usr/bin/ scripts (bsc#1227378).
- Add CVE-2024-4032-private-IP-addrs.patch to fix bsc#1226448
(CVE-2024-4032) rearranging definition of private v global IP
addresses.
- Add CVE-2024-0397-memrace_ssl.SSLContext_cert_store.patch
fixing bsc#1226447 (CVE-2024-0397) by removing memory race
condition in ssl.SSLContext certificate store methods.
- Add bpo38361-syslog-no-slash-ident.patch (bsc#1222109,
gh#python/cpython!16557) fixes syslog making default "ident"
from sys.argv[0].
- Update CVE-2023-52425-libexpat-2.6.0-backport.patch so that
it uses features sniffing, not just comparing version number
(bsc#1220664, bsc#1219559, bsc#1221563, bsc#1222075).
- Remove support-expat-CVE-2022-25236-patched.patch, which was
the previous name of this patch.
- Add CVE-2023-52425-remove-reparse_deferral-tests.patch skipping
failing tests.
- Refresh patches:
- CVE-2023-27043-email-parsing-errors.patch
- fix_configure_rst.patch
- skip_if_buildbot-extend.patch
- bsc#1221854 (CVE-2024-0450) Add
CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
detecting the vulnerability of the "quoted-overlap" zipbomb
(from gh#python/cpython!110016).
- Add bh42369-thread-safety-zipfile-SharedFile.patch (from
gh#python/cpython!26974) required by the previous patch.
- Add expat-260-test_xml_etree-reparse-deferral.patch to make the
interpreter work with patched libexpat in our distros.
- Move all patches from locally sourced to the branch
opensuse-3.6 branch at GitHub repo, and move all metadata to
commits themselves (readable in the headers of each patch).
- Add bpo-41675-modernize-siginterrupt.patch to make Python build
cleanly even on more recent SPs of SLE-15
(gh#python/cpython#85841).
- Remove patches:
- bpo36263-Fix_hashlib_scrypt.patch - fix against bug in
OpenSSL fixed in 1.1.1c (gh#openssl/openssl!8483), so this
patch is redundant on all SUSE-supported distros
- python-3.3.0b1-test-posix_fadvise.patch - protection
against the kernel issues which has been fixed in
gh#torvalds/linux@3d3727cdb07f, which has been included in
all our kernels more recent than SLE-11.
- python-3.3.3-skip-distutils-test_sysconfig_module.patch -
skips a test, which should be relevant only for testing on
Mac OS X systems with universal builds. I have no valid
record, that this test would be ever problematic on Linux.
- bpo-36576-skip_tests_for_OpenSSL-111.patch, which was
included already in Python 3.5.
- (bsc#1219666, CVE-2023-6597) Add
CVE-2023-6597-TempDir-cleaning-symlink.patch (patch from
gh#python/cpython!99930) fixing symlink bug in cleanup of
tempfile.TemporaryDirectory.
- Merge together bpo-36576-skip_tests_for_OpenSSL-111.patch into
skip_SSL_tests.patch, and make them include all conditionals.
- Refresh CVE-2023-27043-email-parsing-errors.patch to
gh#python/cpython!111116, fixing bsc#1210638 (CVE-2023-27043).
Package wicked was updated:
- Update to version 0.6.77 - compat-suse: use iftype in sysctl handling (bsc#1230911, gh#openSUSE/wicked#1043)
- Always generate the ipv4/ipv6 <enabled>true|false</enabled> node
- Inherit all, default and interface sysctl settings also for loopback,
except for use_tempaddr and accept_dad.
- Consider only interface specific accept_redirects sysctl settings.
- Adopt ifsysctl(5) manual page with wicked specific behavior.
- route: fix family and destination processing (bsc#1231060)
- man: improve wicked-config(5) file description (gh#openSUSE/wicked#1039)
- dhcp4: add ignore-rfc3927-1-6 wicked-config(5) option (jsc#PED-10855, gh#openSUSE/wicked#1038)
- team: set arp link watcher interval default to 1s (gh#openSUSE/wicked#1037)
- systemd: use `BindsTo=dbus.service` in favor of `Requisite=` (bsc#1229745)
- compat-suse: fix use of deprecated `INTERFACETYPE=dummy` (boo#1229555)
- arp: don't set target broadcast hardware address (gh#openSUSE/wicked#1036)
- dbus: don't memcpy empty/NULL array value (gh#openSUSE/wicked#1035)
- ethtool: fix leak and free pause data in ethtool_free (gh#openSUSE/wicked#1030)
- Removed patches included in the source archive:
[- 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch]
- compat-suse: fix dummy interfaces configuration with
INTERFACETYPE=dummy (boo#1229555, gh#openSUSE/wicked#1031)
[+ 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch]
- Update to version 0.6.76
- compat-suse: warn user and create missing parent config of
infiniband children (gh#openSUSE/wicked#1027)
- client: fix origin in loaded xml-config with obsolete port
references but missing port interface config, causing a
no-carrier of master (bsc#1226125)
- ipv6: fix setup on ipv6.disable=1 kernel cmdline (bsc#1225976)
- wireless: add frequency-list in station mode (jsc#PED-8715)
- client: fix crash while hierarchy traversing due to loop in
e.g. systemd-nspawn containers (bsc#1226664)
- man: add supported bonding options to ifcfg-bonding(5) man page
(gh#openSUSE/wicked#1021)
- arputil: Document minimal interval for getopts (gh#openSUSE/wicked#1019)
- man: (re)generate man pages from md sources (gh#openSUSE/wicked#1018)
- client: warn on interface wait time reached (gh#openSUSE/wicked#1017)
- compat-suse: fix dummy type detection from ifname to not cause
conflicts with e.g. correct vlan config on dummy0.42 interfaces
(gh#openSUSE/wicked#1016)
- compat-suse: fix infiniband and infiniband child type detection
from ifname (gh#openSUSE/wicked#1015)
- Removed patches included in the source archive:
[- 0001-ifreload-pull-UP-again-on-master-lower-changes-bsc1224100.patch]
[- 0002-increase-arp-retry-attempts-on-sending-bsc1218668.patch]
- arp: increase arp-send retry value to avoid address configuration
failure due to ENOBUF reported by kernel while duplicate address
detection with underlying bonding in 802.3ad mode reporting link
"up & running" too early (bsc#1218668, gh#openSUSE/wicked#1020,
gh#openSUSE/wicked#1022).
[+ 0002-increase-arp-retry-attempts-on-sending-bsc1218668.patch]
- client: fix ifreload to pull UP ports/links again when the config
of their master/lower changed (bsc#1224100,gh#openSUSE/wicked#1014).
[+ 0001-ifreload-pull-UP-again-on-master-lower-changes-bsc1224100.patch]
- Update to version 0.6.75:
- cleanup: fix ni_fsm_state_t enum-int-mismatch warnings
- cleanup: fix overflow warnings in a socket testcase on i586
- ifcheck: report new and deleted configs as changed (bsc#1218926)
- man: improve ARP configuration options in the wicked-config.5
- bond: add ports when master is UP to avoid port MTU revert (bsc#1219108)
- cleanup: fix interface dependencies and shutdown order (bsc#1205604)
- Remove port arrays from bond,team,bridge,ovs-bridge (redundant)
and consistently use config and state info attached to the port
interface as in rtnetlink(7).
- Cleanup ifcfg parsing, schema configuration and service properties
- Migrate ports in xml config and policies already applied in nanny
- Remove "missed config" generation from finite state machine, which
is completed while parsing the config or while xml config migration.
- Issue a warning when "lower" interface (e.g. eth0) config is missed
while parsing config depending on it (e.g. eth0.42 vlan).
- Resolve ovs master to the effective bridge in config and wickedd
- Implement netif-check-state require checks using system relations
from wickedd/kernel instead of config relations for ifdown and add
linkDown and deleteDevice checks to all master and lower references.
- Add a `wicked <ifup|ifdown|ifreload> --dry-run â¦` option to show the
system/config interface hierarchies as notice with +/- marked
interfaces to setup and/or shutdown.
- Removed patches included in the source archive:
[- 0001-addrconf-fix-fallback-lease-drop-bsc-1220996.patch]
[- 0002-extensions-nbft-replace-nvme-show-nbft-with-nvme-nbf.patch]
[- 0003-move-all-attribute-definitions-to-compiler-h.patch]
[- 0004-hide-secrets-in-debug-log-bsc-1221194.patch]
[- 0005-client-do-to-not-convert-sec-to-msec-twice-bsc-1222105.patch]
- client: do not convert sec to msec twice (bsc#1222105)
[+ 0005-client-do-to-not-convert-sec-to-msec-twice-bsc-1222105.patch]
- addrconf: fix fallback-lease drop (bsc#1220996)
[+ 0001-addrconf-fix-fallback-lease-drop-bsc-1220996.patch]
- extensions/nbft: use upstream `nvme nbft show` (bsc#1221358)
[+ 0002-extensions-nbft-replace-nvme-show-nbft-with-nvme-nbf.patch]
- hide secrets in debug log (bsc#1221194)
[+ 0003-move-all-attribute-definitions-to-compiler-h.patch]
[+ 0004-hide-secrets-in-debug-log-bsc-1221194.patch]
- update to version 0.6.74
+ team: add new options like link_watch_policy (jsc#PED-7183)
+ Fix memory leaks in dbus variant destroy and fsm free (gh#openSUSE/wicked#1001)
+ xpath: allow underscore in node identifier (gh#openSUSE/wicked#999)
+ vxlan: don't format unknown rtnl attrs (bsc#1219751)
- removed patches included in the source archive:
[- 0009-ifreload-VLAN-changes-require-device-deletion-bsc-12.patch]
[- 0008-ifcheck-fix-config-changed-check-bsc-1218926.patch]
[- 0007-Fix-ifstatus-exit-code-for-NI_WICKED_ST_NO_CARRIER-s.patch]
[- 0006-dhcp6-omit-the-SO_REUSEPORT-option-bsc-1215692.patch]
[- 0005-duid-fix-comment-for-v6time.patch]
[- 0004-rtnl-parse-peer-address-on-non-ptp-interfaces.patch]
[- 0003-rtnl-pass-ifname-in-newaddr-parsing-and-logging.patch]
[- 0002-system-updater-Parse-updater-format-from-XML-configu.patch]
[- 0001-fix_arp_notify_loop_and_burst_sending.patch]
- ifreload: VLAN changes require device deletion (bsc#1218927)
[+ 0009-ifreload-VLAN-changes-require-device-deletion-bsc-12.patch]
- ifcheck: fix config changed check (bsc#1218926)
[+ 0008-ifcheck-fix-config-changed-check-bsc-1218926.patch]
- client: fix exit code for no-carrier status (bsc#1219265)
[+ 0007-Fix-ifstatus-exit-code-for-NI_WICKED_ST_NO_CARRIER-s.patch]
- dhcp6: omit the SO_REUSEPORT option (bsc#1215692)
[+ 0006-dhcp6-omit-the-SO_REUSEPORT-option-bsc-1215692.patch]
- duid: fix comment for v6time
(https://github.com/openSUSE/wicked/pull/989)
[+ 0005-duid-fix-comment-for-v6time.patch]
- rtnl: fix peer address parsing for non ptp-interfaces
(https://github.com/openSUSE/wicked/pull/987,
https://github.com/openSUSE/wicked/pull/988)
[+ 0003-rtnl-pass-ifname-in-newaddr-parsing-and-logging.patch]
[+ 0004-rtnl-parse-peer-address-on-non-ptp-interfaces.patch]
- system-updater: Parse updater format from XML configuration to
ensure install calls can run.
(https://github.com/openSUSE/wicked/pull/985)
[+ 0002-system-updater-Parse-updater-format-from-XML-configu.patch]
Package expat was updated:
- Fix CVE-2025-59375 / bsc#1249584.- Add patch file:
* CVE-2025-59375.patch
- version update to 2.7.1 for SLE-12
- modified sources
% expatfaq.html
- deleted patches
- config-guess-sub-update.patch (upstreamed)
- expat-2.1.0-CVE-2016-9063.patch (upstreamed)
- expat-2.1.0-heap_buffer_overflow.patch (upstreamed)
- expat-2.1.0-parser_crashes_on_malformed_input.patch (upstreamed)
- expat-2.1.1-CVE-2012-6702.patch (upstreamed)
- expat-CVE-2017-9233.patch (upstreamed)
- expat-CVE-2018-20843.patch (upstreamed)
- expat-CVE-2019-15903-tests.patch (upstreamed)
- expat-CVE-2019-15903.patch (upstreamed)
- expat-CVE-2021-45960.patch (upstreamed)
- expat-CVE-2021-46143.patch (upstreamed)
- expat-CVE-2022-22822.patch (upstreamed)
- expat-CVE-2022-22823.patch (upstreamed)
- expat-CVE-2022-22824.patch (upstreamed)
- expat-CVE-2022-22825.patch (upstreamed)
- expat-CVE-2022-22826.patch (upstreamed)
- expat-CVE-2022-22827.patch (upstreamed)
- expat-CVE-2022-23852.patch (upstreamed)
- expat-CVE-2022-23990.patch (upstreamed)
- expat-CVE-2022-25235.patch (upstreamed)
- expat-CVE-2022-25236-relax-fix.patch (upstreamed)
- expat-CVE-2022-25236.patch (upstreamed)
- expat-CVE-2022-25313-fix-regression.patch (upstreamed)
- expat-CVE-2022-25313.patch (upstreamed)
- expat-CVE-2022-25314-before.patch (upstreamed)
- expat-CVE-2022-25314.patch (upstreamed)
- expat-CVE-2022-25315.patch (upstreamed)
- expat-CVE-2022-40674.patch (upstreamed)
- expat-CVE-2022-43680.patch (upstreamed)
- expat-CVE-2023-52425-1.patch (upstreamed)
- expat-CVE-2023-52425-2.patch (upstreamed)
- expat-CVE-2023-52425-backport-parser-changes.patch (upstreamed)
- expat-CVE-2023-52425-fix-tests.patch (upstreamed)
- expat-CVE-2024-45490.patch (upstreamed)
- expat-CVE-2024-45491.patch (upstreamed)
- expat-CVE-2024-45492.patch (upstreamed)
- expat-CVE-2024-50602.patch (upstreamed)
- expat-alloc-size.patch (upstreamed)
- expat-visibility.patch (upstreamed)
- version update to 2.7.1
Bug fixes:
[#980] #989 Restore event pointer behavior from Expat 2.6.4
(that the fix to CVE-2024-8176 changed in 2.7.0);
affected API functions are:
- XML_GetCurrentByteCount
- XML_GetCurrentByteIndex
- XML_GetCurrentColumnNumber
- XML_GetCurrentLineNumber
- XML_GetInputContext
Other changes:
[#976] #977 Autotools: Integrate files "fuzz/xml_lpm_fuzzer.{cpp,proto}"
with Automake that were missing from 2.7.0 release tarballs
[#983] #984 Fix printf format specifiers for 32bit Emscripten
[#992] docs: Promote OpenSSF Best Practices self-certification
[#978] tests/benchmark: Resolve mistaken double close
[#986] Address compiler warnings
[#990] #993 Version info bumped from 11:1:10 (libexpat*.so.1.10.1)
to 11:2:10 (libexpat*.so.1.10.2); see https://verbump.de/
for what these numbers do
Infrastructure:
[#982] CI: Start running Perl XML::Parser integration tests
[#987] CI: Enforce Clang Static Analyzer clean code
[#991] CI: Re-enable warning clang-analyzer-valist.Uninitialized
for clang-tidy
[#981] CI: Cover compilation with musl
[#983] #984 CI: Cover compilation with 32bit Emscripten
[#976] #977 CI: Protect against fuzzer files missing from future
release archives
- version update to 2.7.0 (CVE-2024-8176 [bsc#1239618])
* Security fixes:
[#893] #973 CVE-2024-8176 -- Fix crash from chaining a large number
of entities caused by stack overflow by resolving use of
recursion, for all three uses of entities:
- general entities in character data ("<e>&g1;</e>")
- general entities in attribute values ("<e k1='&g1;'/>")
- parameter entities ("%p1;")
Known impact is (reliable and easy) denial of service:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C
(Base Score: 7.5, Temporal Score: 7.2)
Please note that a layer of compression around XML can
significantly reduce the minimum attack payload size.
* Other changes:
[#935] #937 Autotools: Make generated CMake files look for
libexpat.@SO_MAJOR@.dylib on macOS
[#925] Autotools: Sync CMake templates with CMake 3.29
[#945] #962 #966 CMake: Drop support for CMake <3.13
[#942] CMake: Small fuzzing related improvements
[#921] docs: Add missing documentation of error code
XML_ERROR_NOT_STARTED that was introduced with 2.6.4
[#941] docs: Document need for C++11 compiler for use from C++
[#959] tests/benchmark: Fix a (harmless) TOCTTOU
[#944] Windows: Fix installer target location of file xmlwf.xml
for CMake
[#953] Windows: Address warning -Wunknown-warning-option
about -Wno-pedantic-ms-format from LLVM MinGW
[#971] Address Cppcheck warnings
[#969] #970 Mass-migrate links from http:// to https://
[#947] #958 ..
[#974] #975 Document changes since the previous release
[#974] #975 Version info bumped from 11:0:10 (libexpat*.so.1.10.0)
to 11:1:10 (libexpat*.so.1.10.1); see https://verbump.de/
for what these numbers do
- no source changes, just adding jira reference: jsc#SLE-21253
- version update to 2.6.4
* Security fixes: [bsc#1232601][bsc#1232579]
[#915] CVE-2024-50602 -- Fix crash within function XML_ResumeParser
from a NULL pointer dereference by disallowing function
XML_StopParser to (stop or) suspend an unstarted parser.
A new error code XML_ERROR_NOT_STARTED was introduced to
properly communicate this situation. // CWE-476 CWE-754
* Other changes:
[#903] CMake: Add alias target "expat::expat"
[#905] docs: Document use via CMake >=3.18 with FetchContent
and SOURCE_SUBDIR and its consequences
[#902] tests: Reduce use of global parser instance
[#904] tests: Resolve duplicate handler
[#317] #918 tests: Improve tests on doctype closing (ex CVE-2019-15903)
[#914] Fix signedness of format strings
[#919] #920 Version info bumped from 10:3:9 (libexpat*.so.1.9.3)
to 11:0:10 (libexpat*.so.1.10.0); see https://verbump.de/
for what these numbers do
- updated keyring [https://build.suse.de/request/show/345282]
- modified sources
% expat.keyring
- Update to 2.6.3:
* Security fixes:
- CVE-2024-45490, bsc#1229930 -- Calling function XML_ParseBuffer with
len < 0 without noticing and then calling XML_GetBuffer
will have XML_ParseBuffer fail to recognize the problem
and XML_GetBuffer corrupt memory.
With the fix, XML_ParseBuffer now complains with error
XML_ERROR_INVALID_ARGUMENT just like sibling XML_Parse
has been doing since Expat 2.2.1, and now documented.
Impact is denial of service to potentially artitrary code
execution.
- CVE-2024-45491, bsc#1229931 -- Internal function dtdCopy can have an
integer overflow for nDefaultAtts on 32-bit platforms
(where UINT_MAX equals SIZE_MAX).
Impact is denial of service to potentially artitrary code
execution.
- CVE-2024-45492, bsc#1229932 -- Internal function nextScaffoldPart can
have an integer overflow for m_groupSize on 32-bit
platforms (where UINT_MAX equals SIZE_MAX).
Impact is denial of service to potentially artitrary code
execution.
* Other changes:
- Autotools: Sync CMake templates with CMake 3.28
- Autotools: Always provide path to find(1) for portability
- Autotools: Ensure that the m4 directory always exists.
- Autotools: Simplify handling of SIZEOF_VOID_P
- Autotools: Support non-GNU sed
- Autotools|CMake: Fix main() to main(void)
- Autotools|CMake: Fix compile tests for HAVE_SYSCALL_GETRANDOM
- Autotools|CMake: Stop requiring dos2unix
- CMake: Fix check for symbols size_t and off_t
- docs|tests: Convert README to Markdown and update
- Windows: Drop support for Visual Studio <=15.0/2017
- Drop needless XML_DTD guards around is_param access
- Fix typo in a code comment
- Version info bumped from 10:2:9 (libexpat*.so.1.9.2)
to 10:3:9 (libexpat*.so.1.9.3); see https://verbump.de/
for what these numbers do
- update to 2.6.2:
* CVE-2024-28757 -- Prevent billion laughs attacks with isolated
use of external parsers (boo#1221289)
* Reject direct parameter entity recursion and avoid the related
undefined behavior
- update to 2.6.1:
* Expose billion laughs API with XML_DTD defined and XML_GE
undefined, regression from 2.6.0
* Make tests independent of CPU speed, and thus more robust
- drop libxml2-fix-xmlwf.1-handling.patch, upstream
- Fix handling of xmlwf.1 to avoid workarounds in specfile:
* Added libxml2-fix-xmlwf.1-handling.patch
- Call buildconf.sh to avoid (future) issues with expat_config.h.in
- Update keyring automatically from keyserver during OBS service run.
- Explicitly use --without-docbook (before it was implicit).
- Include missing files for documentation and examples.
- Add manpage for xmlwf, which is now available in the released tarball.
- Clean the spec file a bit.
- Update to 2.6.0:
* Security fixes:
- CVE-2023-52425 (boo#1219559, bsc#1221563)
- - Fix quadratic runtime issues with big tokens
that can cause denial of service, in partial where
dealing with compressed XML input. Applications
that parsed a document in one go -- a single call to
functions XML_Parse or XML_ParseBuffer -- were not affected.
The smaller the chunks/buffers you use for parsing
previously, the bigger the problem prior to the fix.
Backporters should be careful to no omit parts of
pull request #789 and to include earlier pull request #771,
in order to not break the fix.
- CVE-2023-52426 (boo#1219561)
- - Fix billion laughs attacks for users
compiling *without* XML_DTD defined (which is not common).
Users with XML_DTD defined have been protected since
Expat >=2.4.0 (and that was CVE-2013-0340 back then).
* Bug fixes:
- Fix parse-size-dependent "invalid token" error for
external entities that start with a byte order mark
- Fix NULL pointer dereference in setContext via
XML_ExternalEntityParserCreate for compilation with
XML_DTD undefined
- Protect against closing entities out of order
* Other changes:
- Improve support for arc4random/arc4random_buf
- Improve buffer growth in XML_GetBuffer and XML_Parse
- xmlwf: Support --help and --version
- xmlwf: Support custom buffer size for XML_GetBuffer and read
- xmlwf: Improve language and URL clickability in help output
- examples: Add new example "element_declarations.c"
- Be stricter about macro XML_CONTEXT_BYTES at build time
- Make inclusion to expat_config.h consistent
- Autotools: configure.ac: Support --disable-maintainer-mode
- Autotools: Sync CMake templates with CMake 3.26
- Autotools: Make installation of shipped man page doc/xmlwf.1
independent of docbook2man availability
- Autotools|CMake: Add missing -DXML_STATIC to pkg-config file
section "Cflags.private" in order to fix compilation
against static libexpat using pkg-config on Windows
- Autotools|CMake: Require a C99 compiler
(a de-facto requirement already since Expat 2.2.2 of 2017)
- Autotools|CMake: Fix PACKAGE_BUGREPORT variable
- Autotools|CMake: Make test suite require a C++11 compiler
- CMake: Require CMake >=3.5.0
- CMake: Lowercase off_t and size_t to help a bug in Meson
- CMake: Sort xmlwf sources alphabetically
- CMake|Windows: Fix generation of DLL file version info
- CMake: Build tests/benchmark/benchmark.c as well for
a build with -DEXPAT_BUILD_TESTS=ON
- docs: Document the importance of isFinal + adjust tests
accordingly
- docs: Improve use of "NULL" and "null"
- docs: Be specific about version of XML (XML 1.0r4)
and version of C (C99); (XML 1.0r5 will need a sponsor.)
- docs: reference.html: Promote function XML_ParseBuffer more
- docs: reference.html: Add HTML anchors to XML_* macros
- docs: reference.html: Upgrade to OK.css 1.2.0
- docs: Fix typos
- docs|CI: Use HTTPS URLs instead of HTTP at various places
- Address compiler warnings
- Address clang-tidy warnings
- Version info bumped from 9:10:8 (libexpat*.so.1.8.10)
to 10:0:9 (libexpat*.so.1.9.0); see https://verbump.de/
for what these numbers do
- add upstream signing key and validate source signature
Package augeas was updated:
- Add patch, fix for bsc#1239909 / CVE-2025-2588: * CVE-2025-2588.patch
Package apparmor was updated:
- Add dac_read_search capability for unix_chkpwd to allow it to read the shadow file even if it has 000 permissions. This is needed after the CVE-2024-10041
fix in PAM.
* unix-chkpwd-add-read-capability.path, bsc#1241678
- Addapt the allow-pam_unix-to-execute-unix_chkpwd.patch for SLE12.
(bsc#1241876)
- Remove revert-abi-change-for-unix_chkpwd.patch
- Allow pam_unix to execute unix_chkpwd with abi/3.0
- remove dovecot-unix_chkpwd.diff
- Add allow-pam_unix-to-execute-unix_chkpwd.patch
- Add revert-abi-change-for-unix_chkpwd.patch
(bsc#1234452, bsc#1232234)
- Update profile usr.lib.dovecot.auth and add dovecot-unix_chkpwd.diff
to allow dovecot-auth to execute unix_chkpwd, and add a profile for
unix_chkpwd. This is needed for PAM with CVE-2024-10041 (bsc#1234452)
- Add apparmor-fix-ping6-denied.patch to allow ping to use
IPv6 RAW sockets ( bsc#1230541 ).
Package libyui-ncurses was updated:
- Backport: Prevent buffer overflow when drawing very wide labels (originally for bsc#1211354, now also for bsc#1247975)
- 2.48.3
Package perl was updated:
- do not change the current directory when cloning an open directory handle [bnc#1244079] [CVE-2025-40909]
new patch: perl-dirdup.diff
Package patterns-sles was updated:
- Require kmod-compat rather than kmod. It's kmod-compat that has the tools used by the kernel and scripts (bsc#1215533).
Package libpng16 was updated:
- security update- added patches
CVE-2026-22695 [bsc#1256525], Heap buffer over-read in png_image_finish_read
* libpng16-CVE-2026-22695.patch
- security update
- added patches
CVE-2025-66293 [bsc#1254480], LIBPNG out-of-bounds read in png_image_read_composite
* libpng16-CVE-2025-66293-1.patch
* libpng16-CVE-2025-66293-2.patch
- security update
- modified patches
* libpng16-1.6.8-CVE-2014-0333.patch (-p1)
* libpng16-CVE-2014-9495.patch (-p1)
* libpng16-CVE-2015-0973.patch (-p1)
* libpng16-CVE-2015-8126-complete.patch (-p1)
* libpng16-CVE-2015-8126.patch (-p1)
- added patches
CVE-2025-64505 [bsc#1254157], heap buffer over-read in `png_do_quantize` via malformed palette index
* libpng16-CVE-2025-64505.patch
CVE-2025-64506 [bsc#1254158], heap buffer over-read in `png_write_image_8bit` with 8-bit input and `convert_to_8bit` enabled
* libpng16-CVE-2025-64506.patch
CVE-2025-64720 [bsc#1254159], buffer overflow in `png_image_read_composite` via incorrect palette premultiplication
* libpng16-CVE-2025-64720.patch
CVE-2025-65018 [bsc#1254160], heap buffer overflow in `png_combine_row` triggered via `png_image_finish_read`
* libpng16-CVE-2025-65018.patch
Package mozilla-nss was updated:
- Add bmo1990242.patch to move NSS DB password hash away from SHA-1
- update to NSS 3.112.2
* bmo#1970079 - Prevent leaks during pkcs12 decoding.
* bmo#1988046 - SEC_ASN1Decode* should ensure it has read as many bytes as each length field indicates
- Adding patch bmo1980465.patch to fix bug on s390x (bmo#1980465)
- Adding patch bmo1956754.patch to fix possible undefined behaviour (bmo#1956754)
- update to NSS 3.112.1
* bmo#1982742 - restore support for finding certificates by decoded serial number.
- update to NSS 3.112
* bmo#1963792 - Fix alias for mac workers on try
* bmo#1966786 - ensure all options can be configured with SSL_OptionSet and SSL_OptionSetDefault
* bmo#1931930 - ABI/API break in ssl certificate processing
* bmo#1955971 - remove unnecessary assertion in sec_asn1d_init_state_based_on_template
* bmo#1965754 - update taskgraph to v14.2.1
* bmo#1964358 - Workflow for automation of the release on GitHub when pushing a tag
* bmo#1952860 - fix faulty assertions in SEC_ASN1DecoderUpdate
* bmo#1934877 - Renegotiations should use a fresh ECH GREASE buffer
* bmo#1951396 - update taskgraph to v14.1.1
* bmo#1962503 - Partial fix for ACVP build CI job
* bmo#1961827 - Initialize find in sftk_searchDatabase
* bmo#1963121 - Add clang-18 to extra builds
* bmo#1963044 - Fault tolerant git fetch for fuzzing
* bmo#1962556 - Tolerate intermittent failures in ssl_policy_pkix_ocsp
* bmo#1962770 - fix compiler warnings when DEBUG_ASN1D_STATES or CMSDEBUG are set
* bmo#1961835 - fix content type tag check in NSS_CMSMessage_ContainsCertsOrCrls
* bmo#1963102 - Remove Cryptofuzz CI version check
- update to NSS 3.111
* bmo#1930806 - FIPS changes need to be upstreamed: force ems policy
* bmo#1957685 - Turn off Websites Trust Bit from CAs
* bmo#1937338 - Update nssckbi version following April 2025 Batch of Changes
* bmo#1943135 - Disable SMIME âtrust bitâ for GoDaddy CAs
* bmo#1874383 - Replaced deprecated sprintf function with snprintf in dbtool.c
* bmo#1954612 - Need up update NSS for PKCS 3.1
* bmo#1773374 - avoid leaking localCert if it is already set in ssl3_FillInCachedSID
* bmo#1953097 - Decrease ASAN quarantine size for Cryptofuzz in CI
* bmo#1943962 - selfserv: Add support for zlib certificate compression
- update to NSS 3.110
* bmo#1930806 - FIPS changes need to be upstreamed: force ems policy
* bmo#1954724 - Prevent excess allocations in sslBuffer_Grow
* bmo#1953429 - Remove Crl templates from ASN1 fuzz target
* bmo#1953429 - Remove CERT_CrlTemplate from ASN1 fuzz target
* bmo#1952855 - Fix memory leak in NSS_CMSMessage_IsSigned
* bmo#1930807 - NSS policy updates
* bmo#1951161 - Improve locking in nssPKIObject_GetInstances
* bmo#1951394 - Fix race in sdb_GetMetaData
* bmo#1951800 - Fix member access within null pointer
* bmo#1950077 - Increase smime fuzzer memory limit
* bmo#1949677 - Enable resumption when using custom extensions
* bmo#1952568 - change CN of server12 test certificate
* bmo#1949118 - Part 2: Add missing check in
NSS_CMSDigestContext_FinishSingle
* bmo#1949118 - Part 1: Fix smime UBSan errors
* bmo#1930806 - FIPS changes need to be upstreamed: updated key checks
* bmo#1951491 - Don't build libpkix in static builds
* bmo#1951395 - handle `-p all` in try syntax
* bmo#1951346 - fix opt-make builds to actually be opt
* bmo#1951346 - fix opt-static builds to actually be opt
* bmo#1916439 - Remove extraneous assert
- Removed upstreamed nss-fips-stricter-dh.patch
- Removed upstreamed nss-reproducible-chksums.patch
- Added bmo1962556.patch to fix test failures
- Rebased nss-fips-approved-crypto-non-ec.patch nss-fips-combined-hash-sign-dsa-ecdsa.patch
- update to NSS 3.109
* bmo#1939512 - Call BL_Init before RNG_RNGInit() so that special
SHA instructions can be used if available
* bmo#1930807 - NSS policy updates - fix inaccurate key policy issues
* bmo#1945883 - SMIME fuzz target
* bmo#1914256 - ASN1 decoder fuzz target
* bmo#1936001 - Part 2: Revert âExtract testcases from ssl gtests
for fuzzingâ
* bmo#1915155 - Add fuzz/README.md
* bmo#1936001 - Part 4: Fix tstclnt arguments script
* bmo#1944545 - Extend pkcs7 fuzz target
* bmo#1912320 - Extend certDN fuzz target
* bmo#1944300 - revert changes to HACL* files from bug 1866841
* bmo#1936001 - Part 3: Package frida corpus script
- update to NSS 3.108
* bmo#1923285 - libclang-16 -> libclang-19
* bmo#1939086 - Turn off Secure Email Trust Bit for Security
Communication ECC RootCA1
* bmo#1937332 - Turn off Secure Email Trust Bit for BJCA Global Root
CA1 and BJCA Global Root CA2
* bmo#1915902 - Remove SwissSign Silver CA â G2
* bmo#1938245 - Add D-Trust 2023 TLS Roots to NSS
* bmo#1942301 - fix fips test failure on windows
* bmo#1935925 - change default sensitivity of KEM keys
* bmo#1936001 - Part 1: Introduce frida hooks and script
* bmo#1942350 - add missing arm_neon.h include to gcm.c
* bmo#1831552 - ci: update windows workers to win2022
* bmo#1831552 - strip trailing carriage returns in tools tests
* bmo#1880256 - work around unix/windows path translation issues
in cert test script
* bmo#1831552 - ci: let the windows setup script work without $m
* bmo#1880255 - detect msys
* bmo#1936680 - add a specialized CTR_Update variant for AES-GCM
* bmo#1930807 - NSS policy updates
* bmo#1930806 - FIPS changes need to be upstreamed: FIPS 140-3 RNG
* bmo#1930806 - FIPS changes need to be upstreamed: Add SafeZero
* bmo#1930806 - FIPS changes need to be upstreamed - updated POST
* bmo#1933031 - Segmentation fault in SECITEM_Hash during pkcs12 processing
* bmo#1929922 - Extending NSS with LoadModuleFromFunction functionality
* bmo#1935984 - Ensure zero-initialization of collectArgs.cert
* bmo#1934526 - pkcs7 fuzz target use CERT_DestroyCertificate
* bmo#1915898 - Fix actual underlying ODR violations issue
* bmo#1184059 - mozilla::pkix: allow reference ID labels to begin
and/or end with hyphens
* bmo#1927953 - don't look for secmod.db in nssutil_ReadSecmodDB if
NSS_DISABLE_DBM is set
* bmo#1934526 - Fix memory leak in pkcs7 fuzz target
* bmo#1934529 - Set -O2 for ASan builds in CI
* bmo#1934543 - Change branch of tlsfuzzer dependency
* bmo#1915898 - Run tests in CI for ASan builds with detect_odr_violation=1
* bmo#1934241 - Fix coverage failure in CI
* bmo#1934213 - Add fuzzing for delegated credentials, DTLS short
header and Tls13BackendEch
* bmo#1927142 - Add fuzzing for SSL_EnableTls13GreaseEch and
SSL_SetDtls13VersionWorkaround
* bmo#1913677 - Part 3: Restructure fuzz/
* bmo#1931925 - Extract testcases from ssl gtests for fuzzing
* bmo#1923037 - Force Cryptofuzz to use NSS in CI
* bmo#1923037 - Fix Cryptofuzz on 32 bit in CI
* bmo#1933154 - Update Cryptofuzz repository link
* bmo#1926256 - fix build error from 9505f79d
* bmo#1926256 - simplify error handling in get_token_objects_for_cache
* bmo#1931973 - nss doc: fix a warning
* bmo#1930797 - pkcs12 fixes from RHEL need to be picked up
- remove obsolete patches
* nss-fips-safe-memset.patch
* nss-bmo1930797.patch
- update to NSS 3.107
* bmo#1923038 - Remove MPI fuzz targets.
* bmo#1925512 - Remove globals `lockStatus` and `locksEverDisabled`.
* bmo#1919015 - Enable PKCS8 fuzz target.
* bmo#1923037 - Integrate Cryptofuzz in CI.
* bmo#1913677 - Part 2: Set tls server target socket options in config class
* bmo#1913677 - Part 1: Set tls client target socket options in config class
* bmo#1913680 - Support building with thread sanitizer.
* bmo#1922392 - set nssckbi version number to 2.72.
* bmo#1919913 - remove Websites Trust Bit from Entrust Root
Certification Authority - G4.
* bmo#1920641 - remove Security Communication RootCA3 root cert.
* bmo#1918559 - remove SecureSign RootCA11 root cert.
* bmo#1922387 - Add distrust-after for TLS to Entrust Roots.
* bmo#1927096 - update expected error code in pk12util pbmac1 tests.
* bmo#1929041 - Use random tstclnt args with handshake collection script
* bmo#1920466 - Remove extraneous assert in ssl3gthr.c.
* bmo#1928402 - Adding missing release notes for NSS_3_105.
* bmo#1874451 - Enable the disabled mlkem tests for dtls.
* bmo#1874451 - NSS gtests filter cleans up the constucted buffer
before the use.
* bmo#1925505 - Make ssl_SetDefaultsFromEnvironment thread-safe.
* bmo#1925503 - Remove short circuit test from ssl_Init.
- fix build on loongarch64 (setting it as 64bit arch)
- Remove upstreamed bmo-1400603.patch
- Added nss-bmo1930797.patch to fix failing tests in testsuite
- update to NSS 3.106
* bmo#1925975 - NSS 3.106 should be distributed with NSPR 4.36.
* bmo#1923767 - pk12util: improve error handling in p12U_ReadPKCS12File.
* bmo#1899402 - Correctly destroy bulkkey in error scenario.
* bmo#1919997 - PKCS7 fuzz target, r=djackson,nss-reviewers.
* bmo#1923002 - Extract certificates with handshake collection script.
* bmo#1923006 - Specify len_control for fuzz targets.
* bmo#1923280 - Fix memory leak in dumpCertificatePEM.
* bmo#1102981 - Fix UBSan errors for SECU_PrintCertificate and
SECU_PrintCertificateBasicInfo.
* bmo#1921528 - add new error codes to mozilla::pkix for Firefox to use.
* bmo#1921768 - allow null phKey in NSC_DeriveKey.
* bmo#1921801 - Only create seed corpus zip from existing corpus.
* bmo#1826035 - Use explicit allowlist for for KDF PRFS.
* bmo#1920138 - Increase optimization level for fuzz builds.
* bmo#1920470 - Remove incorrect assert.
* bmo#1914870 - Use libFuzzer options from fuzz/options/\*.options in CI.
* bmo#1920945 - Polish corpus collection for automation.
* bmo#1917572 - Detect new and unfuzzed SSL options.
* bmo#1804646 - PKCS12 fuzzing target.
- requires NSPR 4.36
- update to NSS 3.105
* bmo#1915792 - Allow importing PKCS#8 private EC keys missing public key
* bmo#1909768 - UBSAN fix: applying zero offset to null pointer in sslsnce.c
* bmo#1919577 - set KRML_MUSTINLINE=inline in makefile builds
* bmo#1918965 - Don't set CKA_SIGN for CKK_EC_MONTGOMERY private keys
* bmo#1918767 - override default definition of KRML_MUSTINLINE
* bmo#1916525 - libssl support for mlkem768x25519
* bmo#1916524 - support for ML-KEM-768 in softoken and pk11wrap
* bmo#1866841 - Add Libcrux implementation of ML-KEM 768 to FreeBL
* bmo#1911912 - Avoid misuse of ctype(3) functions
* bmo#1917311 - part 2: run clang-format
* bmo#1917311 - part 1: upgrade to clang-format 13
* bmo#1916953 - clang-format fuzz
* bmo#1910370 - DTLS client message buffer may not empty be on retransmit
* bmo#1916413 - Optionally print config for TLS client and server
fuzz target
* bmo#1916059 - Fix some simple documentation issues in NSS.
* bmo#1915439 - improve performance of NSC_FindObjectsInit when
template has CKA_TOKEN attr
* bmo#1912828 - define CKM_NSS_ECDHE_NO_PAIRWISE_CHECK_KEY_PAIR_GEN
- Fix build error under Leap by rebasing nss-fips-safe-memset.patch.
- update to NSS 3.104
* bmo#1910071 - Copy original corpus to heap-allocated buffer
* bmo#1910079 - Fix min ssl version for DTLS client fuzzer
* bmo#1908990 - Remove OS2 support just like we did on NSPR
* bmo#1910605 - clang-format NSS improvements
* bmo#1902078 - Adding basicutil.h to use HexString2SECItem function
* bmo#1908990 - removing dirent.c from build
* bmo#1902078 - Allow handing in keymaterial to shlibsign to make
the output reproducible
* bmo#1908990 - remove nec4.3, sunos4, riscos and SNI references
* bmo#1908990 - remove other old OS (BSDI, old HP UX, NCR,
openunix, sco, unixware or reliantUnix
* bmo#1908990 - remove mentions of WIN95
* bmo#1908990 - remove mentions of WIN16
* bmo#1913750 - More explicit directory naming
* bmo#1913755 - Add more options to TLS server fuzz target
* bmo#1913675 - Add more options to TLS client fuzz target
* bmo#1835240 - Use OSS-Fuzz corpus in NSS CI
* bmo#1908012 - set nssckbi version number to 2.70.
* bmo#1914499 - Remove Email Trust bit from ACCVRAIZ1 root cert.
* bmo#1908009 - Remove Email Trust bit from certSIGN ROOT CA.
* bmo#1908006 - Add Cybertrust Japan Roots to NSS.
* bmo#1908004 - Add Taiwan CA Roots to NSS.
* bmo#1911354 - remove search by decoded serial in
nssToken_FindCertificateByIssuerAndSerialNumber
* bmo#1913132 - Fix tstclnt CI build failure
* bmo#1913047 - vfyserv: ensure peer cert chain is in db for
CERT_VerifyCertificateNow
* bmo#1912427 - Enable all supported protocol versions for UDP
* bmo#1910361 - Actually use random PSK hash type
* bmo#1911576 - Initialize NSS DB once
* bmo#1910361 - Additional ECH cipher suites and PSK hash types
* bmo#1903604 - Automate corpus file generation for TLS client Fuzzer
* bmo#1910364 - Fix crash with UNSAFE_FUZZER_MODE
* bmo#1910605 - clang-format shlibsign.c
- remove obsolete nss-reproducible-builds.patch
- update to NSS 3.103
* bmo#1908623 - move list size check after lock acquisition in sftk_PutObjectToList.
* bmo#1899542 - Add fuzzing support for SSL_ENABLE_POST_HANDSHAKE_AUTH,
* bmo#1909638 - Follow-up to fix test for presence of file nspr.patch.
* bmo#1903783 - Adjust libFuzzer size limits
* bmo#1899542 - Add fuzzing support for SSL_SetCertificateCompressionAlgorithm,
SSL_SetClientEchConfigs, SSL_VersionRangeSet and SSL_AddExternalPsk
* bmo#1899542 - Add fuzzing support for SSL_ENABLE_GREASE and
SSL_ENABLE_CH_EXTENSION_PERMUTATION
- Add nss-reproducible-builds.patch to make the rpms reproducible,
by using a hardcoded, static key to generate the checksums (*.chk-files)
- Updated nss-fips-approved-crypto-non-ec.patch to enforce
approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113).
- update to NSS 3.102.1
* bmo#1905691 - ChaChaXor to return after the function
- update to NSS 3.102
* bmo#1880351 - Add Valgrind annotations to freebl Chacha20-Poly1305.
* bmo#1901932 - missing sqlite header.
* bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME.
* bmo#1615298 - improve certutil keyUsage, extKeyUsage, and nsCertType keyword handling.
* bmo#1660676 - correct length of raw SPKI data before printing in pp utility.
- Add nss-reproducible-chksums.patch to make NSS-build reproducible
Use key from openssl (bsc#1081723)
- Updated nss-fips-approved-crypto-non-ec.patch to exclude the
SHA-1 hash from SLI approval.
- Updated nss-fips-approved-crypto-non-ec.patch to not pass in
bad targetKeyLength parameters when checking for FIPS approval
after keygen. This was causing false rejections.
- Updated nss-fips-approved-crypto-non-ec.patch to approve
RSA signature verification mechanisms with PKCS padding and
legacy moduli (bsc#1222834).
- Updated nss-fips-approved-crypto-non-ec.patch to enforce
approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113).
- Require `sed` for mozilla-nss-sysinit, as setup-nsssysinit.sh
depends on it and will create a broken, empty config, if sed is
missing (bsc#1227918)
- update to NSS 3.101.2
* bmo#1905691 - ChaChaXor to return after the function
- Added nss-fips-safe-memset.patch, fixing bsc#1222811.
- Removed some dead code from nss-fips-constructor-self-tests.patch.
- Rebased nss-fips-approved-crypto-non-ec.patch on above changes.
- Added nss-fips-aes-gcm-restrict.patch, fixing bsc#1222830.
- Updated nss-fips-approved-crypto-non-ec.patch, fixing bsc#1222813,
bsc#1222814, bsc#1222821, bsc#1222822, bsc#1224118.
- Updated nss-fips-approved-crypto-non-ec.patch and
nss-fips-constructor-self-tests.patch, fixing bsc#1222807,
bsc#1222828, bsc#1222834.
- Updated nss-fips-approved-crypto-non-ec.patch, fixing bsc#1222804,
bsc#1222826, bsc#1222833, bsc#1224113, bsc#1224115, bsc#1224116.
- update to NSS 3.101.1
* bmo#1901932 - missing sqlite header.
* bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME.
- update to NSS 3.101
* bmo#1900413 - add diagnostic assertions for SFTKObject refcount.
* bmo#1899759 - freeing the slot in DeleteCertAndKey if authentication failed
* bmo#1899883 - fix formatting issues.
* bmo#1889671 - Add Firmaprofesional CA Root-A Web to NSS.
* bmo#1899593 - remove invalid acvp fuzz test vectors.
* bmo#1898830 - pad short P-384 and P-521 signatures gtests.
* bmo#1898627 - remove unused FreeBL ECC code.
* bmo#1898830 - pad short P-384 and P-521 signatures.
* bmo#1898825 - be less strict about ECDSA private key length.
* bmo#1854439 - Integrate HACL* P-521.
* bmo#1854438 - Integrate HACL* P-384.
* bmo#1898074 - memory leak in create_objects_from_handles.
* bmo#1898858 - ensure all input is consumed in a few places in mozilla::pkix
* bmo#1884444 - SMIME/CMS and PKCS #12 do not integrate with modern NSS policy
* bmo#1748105 - clean up escape handling
* bmo#1896353 - Use lib::pkix as default validator instead of the old-one
* bmo#1827444 - Need to add high level support for PQ signing.
* bmo#1548723 - Certificate Compression: changing the allocation/freeing of buffer + Improving the documentation
* bmo#1884444 - SMIME/CMS and PKCS #12 do not integrate with modern NSS policy
* bmo#1893404 - Allow for non-full length ecdsa signature when using softoken
* bmo#1830415 - Modification of .taskcluster.yml due to mozlint indent defects
* bmo#1793811 - Implement support for PBMAC1 in PKCS#12
* bmo#1897487 - disable VLA warnings for fuzz builds.
* bmo#1895032 - remove redundant AllocItem implementation.
* bmo#1893334 - add PK11_ReadDistrustAfterAttribute.
* bmo#215997 - Clang-formatting of SEC_GetMgfTypeByOidTag update
* bmo#1895012 - Set SEC_ERROR_LIBRARY_FAILURE on self-test failure
* bmo#1894572 - sftk_getParameters(): Fix fallback to default variable after error with configfile.
* bmo#1830415 - Switch to the mozillareleases/image_builder image
- Follow upstream changes in nss-fips-constructor-self-tests.patch (switch from ec_field_GFp to ec_field_plain)
- Remove part of nss-fips-zeroization.patch that got removed upstream
- update to NSS 3.100
- bmo#1893029 - merge pk11_kyberSlotList into pk11_ecSlotList for
faster Xyber operations.
- bmo#1893752 - remove ckcapi.
- bmo#1893162 - avoid a potential PK11GenericObject memory leak.
- bmo#671060 - Remove incomplete ESDH code.
- bmo#215997 - Decrypt RSA OAEP encrypted messages.
- bmo#1887996 - Fix certutil CRLDP URI code.
- bmo#1890069 - Don't set CKA_DERIVE for CKK_EC_EDWARDS private keys.
- bmo#676118 - Add ability to encrypt and decrypt CMS messages using ECDH.
- bmo#676100 - Correct Templates for key agreement in smime/cmsasn.c.
- bmo#1548723 - Moving the decodedCert allocation to NSS.
- bmo#1885404 - Allow developers to speed up repeated local execution
of NSS tests that depend on certificates.
- update to NSS 3.99
* Removing check for message len in ed25519 (bmo#1325335)
* add ed25519 to SECU_ecName2params. (bmo#1884276)
* add EdDSA wycheproof tests. (bmo#1325335)
* nss/lib layer code for EDDSA. (bmo#1325335)
* Adding EdDSA implementation. (bmo#1325335)
* Exporting Certificate Compression types (bmo#1881027)
* Updating ACVP docker to rust 1.74 (bmo#1880857)
* Updating HACL* to 0f136f28935822579c244f287e1d2a1908a7e552 (bmo#1325335)
* Add NSS_CMSRecipient_IsSupported. (bmo#1877730)
- update to NSS 3.98
* bmo#1780432 - (CVE-2023-5388) Timing attack against RSA decryption
in TLS
* bmo#1879513 - Certificate Compression: enabling the check that
the compression was advertised
* bmo#1831552 - Move Windows workers to nss-1/b-win2022-alpha
* bmo#1879945 - Remove Email trust bit from OISTE WISeKey
Global Root GC CA
* bmo#1877344 - Replace `distutils.spawn.find_executable` with
`shutil.which` within `mach` in `nss`
* bmo#1548723 - Certificate Compression: Updating nss_bogo_shim to
support Certificate compression
* bmo#1548723 - TLS Certificate Compression (RFC 8879) Implementation
* bmo#1875356 - Add valgrind annotations to freebl kyber operations
for constant-time execution tests
* bmo#1870673 - Set nssckbi version number to 2.66
* bmo#1874017 - Add Telekom Security roots
* bmo#1873095 - Add D-Trust 2022 S/MIME roots
* bmo#1865450 - Remove expired Security Communication RootCA1 root
* bmo#1876179 - move keys to a slot that supports concatenation in
PK11_ConcatSymKeys
* bmo#1876800 - remove unmaintained tls-interop tests
* bmo#1874937 - bogo: add support for the -ipv6 and -shim-id shim
flags
* bmo#1874937 - bogo: add support for the -curves shim flag and
update Kyber expectations
* bmo#1874937 - bogo: adjust expectation for a key usage bit test
* bmo#1757758 - mozpkix: add option to ignore invalid subject
alternative names
* bmo#1841029 - Fix selfserv not stripping `publicname:` from -X value
* bmo#1876390 - take ownership of ecckilla shims
* bmo#1874458 - add valgrind annotations to freebl/ec.c
* bmo#864039 - PR_INADDR_ANY needs PR_htonl before assignment to inet.ip
* bmo#1875965 - Update zlib to 1.3.1
- Use %patch -P N instead of deprecated %patchN.
- update to NSS 3.97
* bmo#1875506 - make Xyber768d00 opt-in by policy
* bmo#1871631 - add libssl support for xyber768d00
* bmo#1871630 - add PK11_ConcatSymKeys
* bmo#1775046 - add Kyber and a PKCS#11 KEM interface to softoken
* bmo#1871152 - add a FreeBL API for Kyber
* bmo#1826451 - part 2: vendor github.com/pq-crystals/kyber/commit/e0d1c6ff
* bmo#1826451 - part 1: add a script for vendoring kyber from pq-crystals repo
* bmo#1835828 - Removing the calls to RSA Blind from loader.*
* bmo#1874111 - fix worker type for level3 mac tasks
* bmo#1835828 - RSA Blind implementation
* bmo#1869642 - Remove DSA selftests
* bmo#1873296 - read KWP testvectors from JSON
* bmo#1822450 - Backed out changeset dcb174139e4f
* bmo#1822450 - Fix CKM_PBE_SHA1_DES2_EDE_CBC derivation
* bmo#1871219 - Wrap CC shell commands in gyp expansions
- update to NSS 3.96.1
* bmo#1869408 - Use pypi dependencies for MacOS worker in ./build_gyp.sh
* bmo#1830978 - p7sign: add -a hash and -u certusage (also p7verify cleanups)
* bmo#1867408 - add a defensive check for large ssl_DefSend return values
* bmo#1869378 - Add dependency to the taskcluster script for Darwin
* bmo#1869378 - Upgrade version of the MacOS worker for the CI
- add nss-allow-slow-tests-s390x.patch: "certutil dump keys with
explicit default trust flags" test needs longer than the allowed
6 seconds on s390x
- update to NSS 3.95
* bmo#1842932 - Bump builtins version number.
* bmo#1851044 - Remove Email trust bit from Autoridad de Certificacion
Firmaprofesional CIF A62634068 root cert.
* bmo#1855318 - Remove 4 DigiCert (Symantec/Verisign) Root Certificates
* bmo#1851049 - Remove 3 TrustCor Root Certificates from NSS.
* bmo#1850982 - Remove Camerfirma root certificates from NSS.
* bmo#1842935 - Remove old Autoridad de Certificacion Firmaprofesional
Certificate.
* bmo#1860670 - Add four Commscope root certificates to NSS.
* bmo#1850598 - Add TrustAsia Global Root CA G3 and G4 root certificates.
* bmo#1863605 - Include P-384 and P-521 Scalar Validation from HACL*
* bmo#1861728 - Include P-256 Scalar Validation from HACL*.
* bmo#1861265 - After the HACL 256 ECC patch, NSS incorrectly encodes
256 ECC without DER wrapping at the softoken level
* bmo#1837987 - Add means to provide library parameters to C_Initialize
* bmo#1573097 - clang format
* bmo#1854795 - add OSXSAVE and XCR0 tests to AVX2 detection.
* bmo#1858241 - Typo in ssl3_AppendHandshakeNumber
* bmo#1858241 - Introducing input check of ssl3_AppendHandshakeNumber
* bmo#1573097 - Fix Invalid casts in instance.c
- update to NSS 3.94
* bmo#1853737 - Updated code and commit ID for HACL*
* bmo#1840510 - update ACVP fuzzed test vector: refuzzed with
current NSS
* bmo#1827303 - Softoken C_ calls should use system FIPS setting
to select NSC_ or FC_ variants
* bmo#1774659 - NSS needs a database tool that can dump the low level
representation of the database
* bmo#1852179 - declare string literals using char in pkixnames_tests.cpp
* bmo#1852179 - avoid implicit conversion for ByteString
* bmo#1818766 - update rust version for acvp docker
* bmo#1852011 - Moving the init function of the mpi_ints before
clean-up in ec.c
* bmo#1615555 - P-256 ECDH and ECDSA from HACL*
* bmo#1840510 - Add ACVP test vectors to the repository
* bmo#1849077 - Stop relying on std::basic_string<uint8_t>
* bmo#1847845 - Transpose the PPC_ABI check from Makefile to gyp
- rebased patches
- added nss-fips-test.patch to fix broken test
- Update to NSS 3.93:
* bmo#1849471 - Update zlib in NSS to 1.3.
* bmo#1848183 - softoken: iterate hashUpdate calls for long inputs.
* bmo#1813401 - regenerate NameConstraints test certificates (boo#1214980).
- Rebase nss-fips-pct-pubkeys.patch.
- update to NSS 3.92
* bmo#1822935 - Set nssckbi version number to 2.62
* bmo#1833270 - Add 4 Atos TrustedRoot Root CA certificates to NSS
* bmo#1839992 - Add 4 SSL.com Root CA certificates
* bmo#1840429 - Add Sectigo E46 and R46 Root CA certificates
* bmo#1840437 - Add LAWtrust Root CA2 (4096)
* bmo#1822936 - Remove E-Tugra Certification Authority root
* bmo#1827224 - Remove Camerfirma Chambers of Commerce Root.
* bmo#1840505 - Remove Hongkong Post Root CA 1
* bmo#1842928 - Remove E-Tugra Global Root CA ECC v3 and RSA v3
* bmo#1842937 - Avoid redefining BYTE_ORDER on hppa Linux
- update to NSS 3.91
* bmo#1837431 - Implementation of the HW support check for ADX instruction
* bmo#1836925 - Removing the support of Curve25519
* bmo#1839795 - Fix comment about the addition of ticketSupportsEarlyData
* bmo#1839327 - Adding args to enable-legacy-db build
* bmo#1835357 - dbtests.sh failure in "certutil dump keys with explicit
default trust flags"
* bmo#1837617 - Initialize flags in slot structures
* bmo#1835425 - Improve the length check of RSA input to avoid heap overflow
* bmo#1829112 - Followup Fixes
* bmo#1784253 - avoid processing unexpected inputs by checking for
m_exptmod base sign
* bmo#1826652 - add a limit check on order_k to avoid infinite loop
* bmo#1834851 - Update HACL* to commit 5f6051d2
* bmo#1753026 - add SHA3 to cryptohi and softoken
* bmo#1753026 - HACL SHA3
* bmo#1836781 - Disabling ASM C25519 for A but X86_64
- removed upstreamed patch nss-fix-bmo1836925.patch
- update to NSS 3.90.3
* bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME.
* bmo#1748105 - clean up escape handling.
* bmo#1895032 - remove redundant AllocItem implementation.
* bmo#1836925 - Disable ASM support for Curve25519.
* bmo#1836781 - Disable ASM support for Curve25519 for all but X86_64.
- remove upstreamed nss-fix-bmo1836925.patch
- Adding nss-fips-bsc1223724.patch to fix startup crash of Firefox
when using FIPS-mode (bsc#1223724).
- Added "Provides: nss" so other RPMs that require 'nss' can
be installed (jira PED-6358).
- update to NSS 3.90.2
* bmo#1780432 - (CVE-2023-5388) Timing attack against RSA
decryption in TLS. (bsc#1216198)
* bmo#1867408 - add a defensive check for large ssl_DefSend
return values.
- update to NSS 3.90.1
* bmo#1813401 - regenerate NameConstraints test certificates.
* bmo#1854795 - add OSXSAVE and XCR0 tests to AVX2 detection.
- Remove nss-fix-bmo1813401.patch which is now upstream.
- Add nss-fix-bmo1813401.patch to fix bsc#1214980
Package google-guest-agent was updated:
- Update to version 20250506.01 (bsc#1243254, bsc#1243505) * Make sure agent added connections are activated by NM (#534)
- from version 20250506.00
* wrap NSS cache refresh in a goroutine (#533)
- from version 20250502.01
* Wicked: Only reload interfaces for which configurations are written or changed. (#524)
- from version 20250502.00
* Add AuthorizedKeysCompat to windows packaging (#530)
* Remove error messages from gce_workload_cert_refresh and metadata script runner (#527)
* Update guest-logging-go dependency (#526)
* Add 'created-by' metadata, and pass it as option to logging library (#508)
* Revert "oslogin: Correctly handle newlines at the end of modified files (#520)" (#523)
* Re-enable disabled services if the core plugin was enabled (#522)
* Enable guest services on package upgrade (#519)
* oslogin: Correctly handle newlines at the end of modified files (#520)
* Fix core plugin path (#518)
* Fix package build issues (#517)
* Fix dependencies ran go mod tidy -v (#515)
* Fix debian build path (#514)
* Bundle compat metadata script runner binary in package (#513)
* Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512)
* Update startup/shutdown services to launch compat manager (#503)
* Bundle new gce metadata script runner binary in agent package (#502)
* Revert "Revert bundling new binaries in the package (#509)" (#511)
- from version 20250418.00
* Re-enable disabled services if the core plugin was enabled (#521)
- from version 20250414.00
* Add AuthorizedKeysCompat to windows packaging (#530)
* Remove error messages from gce_workload_cert_refresh and metadata script runner (#527)
* Update guest-logging-go dependency (#526)
* Add 'created-by' metadata, and pass it as option to logging library (#508)
* Revert "oslogin: Correctly handle newlines at the end of modified files (#520)" (#523)
* Re-enable disabled services if the core plugin was enabled (#522)
* Enable guest services on package upgrade (#519)
* oslogin: Correctly handle newlines at the end of modified files (#520)
* Fix core plugin path (#518)
* Fix package build issues (#517)
* Fix dependencies ran go mod tidy -v (#515)
* Fix debian build path (#514)
* Bundle compat metadata script runner binary in package (#513)
* Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512)
* Update startup/shutdown services to launch compat manager (#503)
* Bundle new gce metadata script runner binary in agent package (#502)
* Revert "Revert bundling new binaries in the package (#509)" (#511)
- Update to version 20250327.01 (bsc#1239763, bsc#1239866)
* Remove error messages from gce_workload_cert_refresh and
metadata script runner (#527)
- from version 20250327.00
* Update guest-logging-go dependency (#526)
* Add 'created-by' metadata, and pass it as option to logging library (#508)
* Revert "oslogin: Correctly handle newlines at the end of
modified files (#520)" (#523)
* Re-enable disabled services if the core plugin was enabled (#522)
* Enable guest services on package upgrade (#519)
* oslogin: Correctly handle newlines at the end of modified files (#520)
* Fix core plugin path (#518)
* Fix package build issues (#517)
* Fix dependencies ran go mod tidy -v (#515)
* Fix debian build path (#514)
* Bundle compat metadata script runner binary in package (#513)
* Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512)
* Update startup/shutdown services to launch compat manager (#503)
* Bundle new gce metadata script runner binary in agent package (#502)
* Revert "Revert bundling new binaries in the package (#509)" (#511)
- from version 20250326.00
* Re-enable disabled services if the core plugin was enabled (#521)
- from version 20250324.00
* Enable guest services on package upgrade (#519)
* oslogin: Correctly handle newlines at the end of modified files (#520)
* Fix core plugin path (#518)
* Fix package build issues (#517)
* Fix dependencies ran go mod tidy -v (#515)
* Fix debian build path (#514)
* Bundle compat metadata script runner binary in package (#513)
* Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512)
* Update startup/shutdown services to launch compat manager (#503)
* Bundle new gce metadata script runner binary in agent package (#502)
* Revert "Revert bundling new binaries in the package (#509)" (#511)
* Revert bundling new binaries in the package (#509)
* Fix typo in windows build script (#501)
* Include core plugin binary for all packages (#500)
* Update crypto library to fix CVE-2024-45337 (#499)
* Start packaging compat manager (#498)
* Start bundling ggactl_plugin_cleanup binary in all agent packages (#492)
* scripts: introduce a wrapper to locally build deb package (#490)
* Introduce compat-manager systemd unit (#497)
- from version 20250317.00
* Revert "Revert bundling new binaries in the package (#509)" (#511)
* Revert bundling new binaries in the package (#509)
* Fix typo in windows build script (#501)
* Include core plugin binary for all packages (#500)
* Update crypto library to fix CVE-2024-45337 (#499)
* Start packaging compat manager (#498)
* Start bundling ggactl_plugin_cleanup binary in all agent packages (#492)
* scripts: introduce a wrapper to locally build deb package (#490)
* Introduce compat-manager systemd unit (#497)
- from version 20250312.00
* Revert bundling new binaries in the package (#509)
* Fix typo in windows build script (#501)
* Include core plugin binary for all packages (#500)
* Update crypto library to fix CVE-2024-45337 (#499)
* Start packaging compat manager (#498)
* Start bundling ggactl_plugin_cleanup binary in all agent packages (#492)
* scripts: introduce a wrapper to locally build deb package (#490)
* Introduce compat-manager systemd unit (#497)
- from version 20250305.00
* Revert bundling new binaries in the package (#509)
* Fix typo in windows build script (#501)
* Include core plugin binary for all packages (#500)
* Update crypto library to fix CVE-2024-45337 (#499)
* Start packaging compat manager (#498)
* Start bundling ggactl_plugin_cleanup binary in all agent packages (#492)
* scripts: introduce a wrapper to locally build deb package (#490)
* Introduce compat-manager systemd unit (#497)
- from version 20250304.01
* Fix typo in windows build script (#501)
- from version 20250214.01
* Include core plugin binary for all packages (#500)
- from version 20250214.00
* Update crypto library to fix CVE-2024-45337 (#499)
- from version 20250212.00
* Start packaging compat manager (#498)
* Start bundling ggactl_plugin_cleanup binary in all agent packages (#492)
- from version 20250211.00
* scripts: introduce a wrapper to locally build deb package (#490)
* Introduce compat-manager systemd unit (#497)
- from version 20250207.00
* vlan: toggle vlan configuration in debian packaging (#495)
* vlan: move config out of unstable section (#494)
* Add clarification to comments regarding invalid NICs and the
`invalid` tag. (#493)
* Include interfaces in lists even if it has an invalid MAC. (#489)
* Fix windows package build failures (#491)
* vlan: don't index based on the vlan ID (#486)
* Revert PR #482 (#488)
* Remove Amy and Zach from OWNERS (#487)
* Skip interfaces in interfaceNames() instead of erroring if there is an (#482)
* Fix Debian packaging if guest agent manager is not checked out (#485)
- from version 20250204.02
* force concourse to move version forward.
- from version 20250204.01
* vlan: toggle vlan configuration in debian packaging (#495)
- from version 20250204.00
* vlan: move config out of unstable section (#494)
* Add clarification to comments regarding invalid NICs and the
`invalid` tag. (#493)
- from version 20250203.01
* Include interfaces in lists even if it has an invalid MAC. (#489)
- from version 20250203.00
* Fix windows package build failures (#491)
* vlan: don't index based on the vlan ID (#486)
* Revert PR #482 (#488)
* Remove Amy and Zach from OWNERS (#487)
* Skip interfaces in interfaceNames() instead of erroring if there is an (#482)
* Fix Debian packaging if guest agent manager is not checked out (#485)
- from version 20250122.00
* 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)
- 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)
- Update to version 20241018.01 (bsc#1231775, bsc#1231776)
* Add support for including agent manager in guest-agent package (#456)
* plugin manager: Introduce the systemd service file (#455)
* documentation: Update metadata script runner details (#453)
- from version 20241013.00
* Update OWNERS (#452)
- from version 20241011.01
* SUSE no overwrite bug fix, Ubuntu 18.04 exception (#451)
- from version 20241011.00
* Skip MDS setup by default for this release (#450)
- from version 20241010.01
* Revert "network/netplan: Adjust link-local accordingly (#443)" (#448)
* Set enable regardless of previous check failed or not (#447)
- from version 20241009.03
* Avoid unnecessary reloads, check before overwriting configs (#446)
- from version 20241009.02
* network/netplan: Do generate instead of apply (#445)
- from version 20241009.01
* Skip SetupInterfaces if configs are already applied (#444)
* network/netplan: Adjust link-local accordingly (#443)
* Repeated logging could be mistaken for a recurring issue,
log mds mtls endpoint error only once (#439)
* Retry MDS PUT operation, reload netplan/networkctl
only if configs are changed (#438)
* Log interface state after setting up network (#437)
* network: Debian 12 rollback only if default netplan is ok (#436)
- from version 20240930.01
* Change mtls mds defaults, update log message to assure error is harmless (#434)
- from version 20240930.00
* network: Restore Debian 12 netplan configuration. (#433)
* network: Remove primary NIC left over configs. (#432)
* Update VLAN interfaces format to match with MDS (#431)
* Fix panics in agent when setting up VLAN with netplan (#430)
* Add VLAN NIC support for NetworkManager (#429)
* Fix debian12 netplan config issue, use ptr receiver (#428)
* Update README to reflect new network manager changes (#427)
* Introduce a configuration toggle for enabling/disabling cloud logging (#413)
* Adapt and update config key to be consistent with MDS (#426)
* Allow users to enable/disable the mds mtls via metadata key (#423)
* Make primary nic management config consistent across all network managers (#422)
* Document disabling account manager on AD (#421)
* Update README with MDS MTLS docs (#418)
* Avoid writing configuration files when they already exist on wicked and (#410)
* Update golang.org/x/net dependencies to catch up on CVEs (#412)
* Get rid of deperecated dependencies in snapshot service generate code (#411)
* Fix where agent panics on nil event (#409)
* Configure primary nic if only set in cfg file (#408)
* Update NIC management strategy (#402)
* Only release dhclient leases for an interface if the
respective dhclient is still running (#407)
* Disable OS Login without pruning off any extra suffix. (#400)
* Skip root cert rotation if installed once (#405)
* Add ipv6 support to guest agent (#404)
* Update Accounts documentation (#403)
* Update google-startup-scripts.service to enable logging (#399)
* Network subsystem remove os rules (#396)
* oslogin: Don't remove sshca watcher when oslogin is disabled (#398)
* Update dependencies to catch up on CVE fixes (#397)
* Network manager netplan implementation (#386)
* Update dependencies to catch up on CVE fixes (#391)
* Log current available routes on error (#388)
* Fix command monitor bugs (#389)
* windows account: Ignore "user already belogs to group" error (#387)
* Add more error logging in snapshot handling requests, use common retry util (#384)
* All non-200 status code from MDS should raise error (#383)
* Change metadata key to enable-oslogin-certificates (#382)
* Update dhclient pid/lease file directory to abide apparmor rules (#381)
* Add COS homedir-gid patch to upstream. (#365)
* Add require-oslogin-certificates logic to disable keys (#368)
* systemd-networkd: Support Debian 12's version (#372)
* Minor update typo in comment (#380)
* NetworkManager: Only set secondary interfaces as up (#378)
* address manager: Make sure we check for oldMetadata (#375)
* network: Early setup network (#374)
* NetworkManager: Fix ipv6 and ipv4 mode attribute (#373)
* Network Manager: Make sure we clean up ifcfg files (#371)
* metadata script runner: Fix script download (#370)
* oslogin: Avoid adding extra empty line at the end of /etc/security/group.conf (#369)
* Dynamic vlan (#361)
* Check for nil response (#366)
* Create NetworkManager implementation (#362)
* Skip interface manager on Windows (#363)
* network: Remove ignore setup (#360)
* Create wicked network service implementation and its respective unit (#356)
* Update metadata script runner, add tests (#357)
* Refactor guest-agent to use common retry util (#355)
* Flush logs before exiting #358 (#359)
* Create systemd-networkd unit tests. (#354)
* Update network manager unit tests (#351)
* Implement retry util (#350)
* Refactor utils package to not dump everything unrelated into one file (#352)
* Set version on metadata script runner (#353)
* Implement cleanup of deprecated configuration directives (#348)
* Ignore DHCP offered routes only for secondary nics (#347)
* Deprecate DHClient in favor of systemd-networkd (#342)
* Generate windows and linux licenses (#346)
* Remove quintonamore from OWNERS (#345)
* Delete integration tests (#343)
- Update to version 20240816.00
* Add configuration toggle to enable/disable use
of OS native certificate stores (#419)
* Fix dependencies in stable branch #412 (#415)
* Update dep: golang.org/x/crypto to v0.17.0
* Update dep: google.golang.org/protobuf to 1.33.0
* Update dep: golang.org/x/net to 0.17.0
* Update dep: google.golang.org/grpc to v1.57.1
- from version 20240813.00
* Update README with MDS MTLS docs (#418)
- from version 20240808.01
* Avoid writing configuration files when they already
exist on wicked and NetworkManager (#410)
- from version 20240808.00
* Update golang.org/x/net dependencies
to catch up on CVEs (#412)
- from version 20240805.00
* Get rid of deperecated dependencies in
snapshot service generate code (#411)
- Drop dont_overwrite_ifcfg.patch, fixed upstream
- Update to version 20240802.00
* Fix where agent panics on nil event (#409)
- from version 20240801.00
* Configure primary nic if only set in cfg file (#408)
* Update NIC management strategy (#402)
* Only release dhclient leases for an interface if the respective dhclient is still running (#407)
* Disable OS Login without pruning off any extra suffix. (#400)
* Skip root cert rotation if installed once (#405)
* Add ipv6 support to guest agent (#404)
* Update Accounts documentation (#403)
* Update google-startup-scripts.service to enable logging (#399)
* Network subsystem remove os rules (#396)
* oslogin: don't remove sshca watcher when oslogin is disabled (#398)
* Update dependencies to catch up on CVE fixes (#397)
* Network manager netplan implementation (#386)
* Update dependencies to catch up on CVE fixes (#391)
* Log current available routes on error (#388)
* Fix command monitor bugs (#389)
* Windows account: ignore "user already belogs to group" error (#387)
* Add more error logging in snapshot handling requests, use common retry util (#384)
* All non-200 status code from MDS should raise error (#383)
* Change metadata key to enable-oslogin-certificates (#382)
* Update dhclient pid/lease file directory to abide apparmor rules (#381)
* Add COS homedir-gid patch to upstream. (#365)
* Add require-oslogin-certificates logic to disable keys (#368)
* systemd-networkd: support debian 12's version (#372)
* Minor update typo in comment (#380)
* NetworkManager: only set secondary interfaces as up (#378)
* address manager: make sure we check for oldMetadata (#375)
* network: early setup network (#374)
* NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
* Network Manager: make sure we clean up ifcfg files (#371)
* metadata script runner: fix script download (#370)
* oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
* Dynamic vlan (#361)
* Check for nil response (#366)
* Create NetworkManager implementation (#362)
* Skip interface manager on Windows (#363)
* network: remove ignore setup (#360)
* Create wicked network service implementation and its respective unit (#356)
* Update metadata script runner, add tests (#357)
* Refactor guest-agent to use common retry util (#355)
* Flush logs before exiting #358 (#359)
* Create systemd-networkd unit tests. (#354)
* Update network manager unit tests (#351)
* Implement retry util (#350)
* Refactor utils package to not dump everything unrelated into one file (#352)
* Set version on metadata script runner (#353)
* Implement cleanup of deprecated configuration directives (#348)
* Ignore DHCP offered routes only for secondary nics (#347)
* Deprecate DHClient in favor of systemd-networkd (#342)
* Generate windows and linux licenses (#346)
* Remove quintonamore from OWNERS (#345)
* Delete integration tests (#343)
- from version 20240716.00
* Update dep: golang.org/x/crypto to v0.17.0
* Update dep: google.golang.org/protobuf to 1.33.0
* Update dep: golang.org/x/net to 0.17.0
* Update dep: google.golang.org/grpc to v1.57.1
- Update to version 20240701.00
* Update google-startup-scripts.service to enable logging (#399)
- Update to version 20240611.01
* Network subsystem remove os rules (#396)
* oslogin: don't remove sshca watcher when oslogin is disabled (#398)
* update dependencies to catch up on CVE fixes (#397)
* Network manager netplan implementation (#386)
* update dependencies to catch up on CVE fixes (#391)
* Log current available routes on error (#388)
* Fix command monitor bugs (#389)
* windows account: ignore "user already belogs to group" error (#387)
* Add more error logging in snapshot handling requests, use common retry util (#384)
* All non-200 status code from MDS should raise error (#383)
* change metadata key to enable-oslogin-certificates (#382)
* Update dhclient pid/lease file directory to abide apparmor rules (#381)
* Add COS homedir-gid patch to upstream. (#365)
* Add require-oslogin-certificates logic to disable keys (#368)
* systemd-networkd: support debian 12's version (#372)
* Minor update typo in comment (#380)
* NetworkManager: only set secondary interfaces as up (#378)
* address manager: make sure we check for oldMetadata (#375)
* network: early setup network (#374)
* NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
* Network Manager: make sure we clean up ifcfg files (#371)
* metadata script runner: fix script download (#370)
* oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
* Dynamic vlan (#361)
* Check for nil response (#366)
* Create NetworkManager implementation (#362)
* Skip interface manager on Windows (#363)
* network: remove ignore setup (#360)
* Create wicked network service implementation and its respective unit (#356)
* Update metadata script runner, add tests (#357)
* Refactor guest-agent to use common retry util (#355)
* Flush logs before exiting #358 (#359)
* Create systemd-networkd unit tests. (#354)
* Update network manager unit tests (#351)
* Implement retry util (#350)
* Refactor utils package to not dump everything unrelated into one file (#352)
* Set version on metadata script runner (#353)
* Implement cleanup of deprecated configuration directives (#348)
* ignore DHCP offered routes only for secondary nics (#347)
* Deprecate DHClient in favor of systemd-networkd (#342)
* Generate windows and linux licenses (#346)
* Remove quintonamore from OWNERS (#345)
* Delete integration tests (#343)
- from version 20240528.00
* update dep: golang.org/x/crypto to v0.17.0
* update dep: google.golang.org/protobuf to 1.33.0
* update dep: golang.org/x/net to 0.17.0
* update dep: google.golang.org/grpc to v1.57.1
- Update to version 20240314.00 (bsc#1221900, bsc#1221901)
* NetworkManager: only set secondary interfaces as up (#378)
* address manager: make sure we check for oldMetadata (#375)
* network: early setup network (#374)
* NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
* Network Manager: make sure we clean up ifcfg files (#371)
* metadata script runner: fix script download (#370)
* oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
* Dynamic vlan (#361)
* Check for nil response (#366)
* Create NetworkManager implementation (#362)
* Skip interface manager on Windows (#363)
* network: remove ignore setup (#360)
* Create wicked network service implementation and its respective unit (#356)
* Update metadata script runner, add tests (#357)
* Refactor guest-agent to use common retry util (#355)
* Flush logs before exiting #358 (#359)
- Refresh patches for new version
* dont_overwrite_ifcfg.patch
- No need for double %setup.
- Use %patch -P N instead of deprecated %patchN.
- Update to version 20240213.00
* Create systemd-networkd unit tests (#354)
- from version 20240209.00
* Update network manager unit tests (#351)
- from version 20240207.02
* Implement retry util (#350)
- from version 20240207.01
* Refactor utils package to not dump everything unrelated into one file (#352)
- from version 20240207.00
* Set version on metadata script runner (#353)
* Implement cleanup of deprecated configuration directives (#348)
* Ignore DHCP offered routes only for secondary nics (#347)
* Deprecate DHClient in favor of systemd-networkd (#342)
* Generate windows and linux licenses (#346)
- from version 20240122.00
* Remove quintonamore from OWNERS (#345)
- from version 20240111.00
* Delete integration tests (#343)
- from version 20240109.00
* Update licenses with dependencies of go-winio (#339)
* Add github.com/Microsoft/go-winio to third party licensing (#337)
- Add explicit versioned dependency on google-guest-oslogin (bsc#1219642)
- Refresh patches for new version
* dont_overwrite_ifcfg.patch
- Update to version 20231214.00
* Fix snapshot test failure (#336)
- from version 20231212.00
* Implement json-based command messaging system for guest-agent (#326)
- from version 20231118.00
* sshca: Remove certificate caching (#334)
- from version 20231115.00
* revert: 3ddd9d4a496f7a9c591ded58c3f541fd9cc7e317 (#333)
* Update script runner to use common cfg package (#331)
- Update to version 20231110.00
* Update Google UEFI variable (#329)
* Update owners (#328)
- from version 20231103.00
* Make config parsing order consistent (#327)
- Update to version 20231031.01 (bsc#1216547, bsc#1216751)
* Add prefix to scheduler logs (#325)
- from version 20231030.00
* Test configuration files are loaded in the documented
order. Fix initial integration test. (#324)
* Enable mTLS by default (#323)
- from version 20231026.00
* Rotate MDS root certificate (#322)
- from version 20231020.00
* Update response struct, add tests (#315)
* Don't try to schedule mTLS job twice (#317)
- from version 20231019.00
* snapshot: Add context cancellation handling (#318)
- Bump the golang compiler version to 1.21 (bsc#1216546)
- Update to version 20231016.00
* instance setup: trust/rely on metadata package's retry (#316)
- from version 20231013.01
* Update known cert dirs for updaters (#314)
- from version 20231011.00
* Verify cert refresher is enabled before running (#312)
- from version 20231009.00
* Add support for the SSH key options (#296)
- from version 20231006.01
* Events interface improvement (#290)
- from version 20231006.00
* Refactor script runner to use common metadata package (#311)
* Schedule MTLS job before notifying systemd (#310)
* Refactor authorized keys to use metadata package (#300)
- from version 20231005.00
* docs update: add configuration and event manager's docs. (#309)
- from version 20231004.01
* Fix license header (#301)
* packaging(deb): add epoch to oslogin dep declaration (#308)
- from version 20231004.00
* packaging(deb): ignore suffix of version (#306)
* packaging: force epoch and ignore suffix of version (#305)
- from version 20231003.01
* oslogin: declare explicitly dependency (#304)
* oslogin: remove Unstable.pamless_auth_stack feature flag (#303)
- from version 20231003.00
* oslogin: resort ssh configuration keys (#299)
- from version 20230925.00
* oslogin: introduce a feature flag to cert auth (#298)
- from version 20230923.00
* gitignore: unify ignore in the root dir (#297)
- from version 20230921.01
* managers: we accidentally disabled addressMgr, bring it back (#295)
* cfg: fix typos (#294)
* cfg: config typos (#293)
* cfg: introduce a configuration management package (#288)
- from version 20230921.00
* mtls: bring it back (#292)
- from version 20230920.01
* Fix permissions on file created by SaferWriteFile() (#291)
- from version 20230920.00
* sshca: re-enable the event watcher & handler (#289)
- from version 20230919.01
* oslogin: add PAMless Authorization Stack configuration (#285)
- from version 20230919.00
* Preparing it for review (#287)
* sshca: make sure to restore SELinux context of the pipe (#286)
* remove deprecated usage, fix warnings (#282)
* Update system store (#278)
* Update workload certificate endpoints, use metadata package (#275)
* metadata: use url package to form metadata URLs (#284)
- from version 20230913.00
* release prep: disable ssh trusted ca module (#281)
- from version 20230912.00
* New Guest Agent Release (#280)
- from version 20230909.00
* Revert "service: remove the use of the service library (#273)" (#276)
* service: remove the use of the service library (#273)
- from version 20230906.01
* Store keys to machine keyset (#272)
- from version 20230905.00
* restorecon: first try to determine if it's installed (#271)
* run: change all commands to use CommandContext (#268)
* Notify systemd after scheduling required jobs (#270)
* Store certs in ProgramData instead of Program Files (#269)
* metadata watcher: remove local retry & implement unit tests (#267)
* run: split command running utilities into its own package (#265)
- Update to version 20230828.00
* snapshot: Use main context rather than create its own (#266)
- from version 20230825.01
* Verify if cert was successfully added to certpool (#264)
- from version 20230825.00
* Find previous cert for cleanup using one stored on disk (#263)
- from version 20230823.00
* Revert "sshtrustedca: configure selinux context
for sshtrustedca pipe (#256)" (#262)
* Update credentials directory on Linux (#260)
- from version 20230821.00
* Update owners (#261)
- from version 20230819.00
* Revert "guest-agent: prepare for public release (#258)" (#259)
- from version 20230817.00
* guest-agent: prepare for public release (#258)
- from version 20230816.01
* Enable telemetry collection by default (#253)
- from version 20230816.00
* Add pkcs12 license and update retry logic (#257)
* sshtrustedca: Configure selinux context for sshtrustedca pipe (#256)
* Store windows certs in certstore (#255)
* events: Multiplex event watchers (#250)
* Scheduler fixes (#254)
* Update license files (#251)
* Run telemetry every 24 hours, record pretty name on linux (#248)
- Update to version 20230811.00
* sshca: move the event handler to its own package (#247)
- from version 20230809.02
* Move scheduler package to google_guest_agent (#249)
- from version 20230809.01
* Add scheduler utility to run jobs at interval (#244)
- from version 20230809.00
* sshca: transform the format from json to openssh (#246)
- from version 20230803.00
* Add support for reading UEFI variables on windows (#243)
- from version 20230801.03
* sshtrustedca watcher: fix concurrency error (#242)
- from version 20230801.02
* metadata: add a delta between http client timeout and hang (#241)
- from version 20230801.00
* metadata: properly set request config (#240)
* main: bring back the mds client initialization (#239)
* metadata: don't try to use metadata before agentInit() is done (#238)
* Add (disabled) telemetry logic to GuestAgent (#219)
* metadata event handler: updates and bug fixes (#235)
* Verify client credentials are signed by root CA before writing on disk (#236)
* metadata: properly handle context cancelation (#234)
* metadata: fix context cancelation error check (#233)
* metadata: remove the sleep around metadata in instance setup (#232)
* metadata: implement backoff strategy (#231)
* Decrypt and store client credentials on disk (#230)
* Upgrade Go version 1.20 (#228)
* Fetch guest credentials and add MDS response proto (#226)
* metadata: pass main context to WriteGuestAttributes() (#227)
* Support for reading & writing Root CA cert from UEFI variable (#225)
* ssh_trusted_ca: enable the feature (#224)
* sshTrustedCA: add pipe event handler (#222)
* events: start using events layer (#223)
- from version 20230726.00
* events: introducing a events handling subsystem (#221)
- from version 20230725.00
* metadata: add metadata client interface (#220)
- from version 20230711.00
* metadata: moving to its own package (#218)
- from version 20230707.00
* snapshot: fix request handling error (#217)
- Bump Go API version to 1.20
Package util-linux was updated:
- agetty: Prevent login cursor escape (bsc#1194818, util-linux-agetty-prevent-cursor-escape.patch).
- Don't delete binaries not common for all architectures. Create an
util-linux-extra subpackage instead, so users of third party
tools can use them. (bsc#1222285)
- fix Xen virtualization type misidentification bsc#1215918
lscpu-fix-parameter-order-for-ul_prefix_fopen.patch
- Properly neutralize escape sequences in wall
(util-linux-CVE-2024-28085.patch, bsc#1221831, CVE-2024-28085,
and its prerequisites: util-linux-fputs_careful1.patch,
util-linux-wall-migrate-to-memstream.patch
util-linux-fputs_careful2.patch).
Package rsync was updated:
- Security update (CVE-2025-10158, bsc#1254441): rsync: Out of bounds array access via negative index
- Add rsync-CVE-2025-10158.patch
- Fix bsc#1249363 - rsync client sometimes unable to list modules
* Fix order of arguments in rsync-fix-daemon-proto-32.patch
* Change spec fie to use %patch -P n -p1 syntax to conform to rpmlint
- Fix bsc#1239649 - rsync bwlimit=0 option was broken by CVE-2024-12088 fix.
* Add rsync-fix-bwlimit.patch
* bwlimit=0 specifies no limit properly now.
- 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 perl-Bootloader was updated:
- merge gh#openSUSE/perl-bootloader#166- log grub2-install errors correctly (bsc#1221470)
- 0.947
- merge gh#openSUSE/perl-bootloader#161
- support old grub versions (<= 2.02) that used /usr/lib
(bsc#1218842)
- create EFI boot fallback directory if necessary
- 0.946
- merge gh#openSUSE/perl-bootloader#157
- bootloader_entry script can have an optional 'force-default'
argument (bsc#1215064)
- skip warning about unsupported options when in compat mode
- 0.945
Package regionServiceClientConfigGCE was updated:
- Update to version 5.0.0 (bsc#1246995) + SLE 16 python-requests requiers SSL v3 certificates. Update 2
region server certs to support SLE 16 when it gets released.
- Update conditional to handle name change of metadata package
in SLE 16 (bsc#1242063)
- Version 4.2.0 (jsc#PCT-361)
+ Add IPv6 certs to supprt access of the update infrastructure via
IPv6 on GCE instances.
+ Add noipv6.patch
- Update to version 4.1.0 (bsc#1217538)
+ Replace 162.222.182.90 and 35.187.193.56 (length 4096):
rgnsrv-gce-asia-northeast1 -> 162.222.182.90 expires in 9 years
rgnsrv-gce-us-central1 -> 35.187.193.56 expires in 10 years
- Update to version 4.0.1 (bsc#1217538)
+ Replace 130.211.242.136.pem and 130.211.88.88.pem certs
expiring in 8 years and new length of 4096
These certs will replace the current certs that
expire soon
- Update to version 4.0.0 (bsc#1199668)
+ Move the cert location to /usr for compatibility with ro setup of
SLE-Micro
+ Fix url in spec file to pint to the proper location of the source
Package curl was updated:
- Security fix: [bsc#1256105, CVE-2025-14017] * call ldap_init() before setting the options
* Add patch curl-CVE-2025-14017.patch
- Security fixes:
* [bsc#1255731, CVE-2025-14524] bearer token leak on cross-protocol redirect
* [bsc#1255733, CVE-2025-15079] set both knownhosts options to the same file
* [bsc#1255732, CVE-2025-14819] toggling CURLSSLOPT_NO_PARTIALCHAIN makes a different CA cache
* Add patches:
- curl-CVE-2025-14524.patch
- curl-CVE-2025-15079.patch
- curl-CVE-2025-14819.patch
- Security fixes:
* [bsc#1249191, CVE-2025-9086] Out of bounds read for cookie path
* [bsc#1249348, CVE-2025-10148] Predictable WebSocket mask
* Add patches:
- curl-CVE-2025-9086.patch
- curl-CVE-2025-10148.patch
- 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
- Security fix: [bsc#1234068, CVE-2024-11053]
* curl could leak the password used for the first host to the
followed-to host under certain circumstances.
* netrc: address several netrc parser flaws
* Add curl-CVE-2024-11053.patch
- Security fix: [bsc#1232528, CVE-2024-9681]
* HSTS subdomain overwrites parent cache entry
* Add curl-CVE-2024-9681.patch
- Make special characters in URL work with aws-sigv4 [bsc#1230516]
* http_aws_sigv4: canonicalize the query [fc76a24c]
* test439: verify query canonization for aws-sigv4 [65661016]
* http_aws_sigv4: skip the op if the query pair is zero bytes [16bdc09e]
* aws_sigv4: the query canon code miscounted URL encoded input [a1532a33]
* http_aws_sigv4: canonicalise valueless query params [bbba69da]
* aws-sigv4: url encode the canonical path [768909d8]
* Add upstream patches:
- curl-aws_sigv4-canonicalize-the-query.patch
- curl-aws_sigv4-verify-query-canonization.patch
- curl-aws_sigv4-skip-the-op-if-the-query-pair-is-zero-bytes.patch
- curl-aws_sigv4-the-query-canon-code-miscounted-url-encoded-input.patch
- curl-aws_sigv4-canonicalise-valueless-query-params.patch
- curl-aws_sigv4-url-encode-the-canonical-path.patch
- Security fix: [bsc#1230093, CVE-2024-8096]
* curl: OCSP stapling bypass with GnuTLS
* Add curl-CVE-2024-8096.patch
- Security fix: [bsc#1228535, CVE-2024-7264]
* curl: ASN.1 date parser overread
* Add curl-CVE-2024-7264.patch
- Security fix: [bsc#1221665, CVE-2024-2004]
* Usage of disabled protocol
* Add curl-CVE-2024-2004.patch
- Security fix: [bsc#1221667, CVE-2024-2398]
* curl: HTTP/2 push headers memory-leak
* Add curl-CVE-2024-2398.patch
- Fix: libssh: Implement SFTP packet size limit (bsc#1216987)
* Add curl-libssh_Implement_SFTP_packet_size_limit.patch
- Security fixes:
* [bsc#1217573, CVE-2023-46218] cookie mixed case PSL bypass
* [bsc#1217574, CVE-2023-46219] HSTS long file name clears contents
* Add curl-CVE-2023-46218.patch curl-CVE-2023-46219.patch
Package shim was updated:
- Update shim to 15.8-150300.4.20.2 from SLE15-SP3 + Version: 15.8, "Thu Apr 18 2024"
+ Update the SLE signatures
+ Include the fixes for (bsc#1215099,CVE-2023-40546),
(bsc#1215098,CVE-2023-40547), (bsc#1215103,CVE-2023-40551),
(bsc#1215102,CVE-2023-40550), (bsc#1215101,CVE-2023-40549),
(bsc#1215100,CVE-2023-40548), bsc#1205588, bsc#1202120, bsc#1201066,
(bsc#1198458, CVE-2022-28737), bsc#1198101, bsc#1193315, bsc#1193282
Package cloud-regionsrv-client was updated:
- Update version to 10.5.2 (bsc#1247539) + When an instance fails verification server side the default credentials
were left behind requireing manual intervantion prior to the next
registration attempt.
+ Fix issue triggered when using instance-billing-flavor-check due to
IP address handling as object rather than string introduced 10.5.0
- Update version to 10.5.1
+ Fix issue with picking up configured server names from the
regionsrv config file. Previously only IP addresses were collected
+ Update scriptlet for package uninstall to avoid issues in the
build service
- Update version to 10.5.0
+ Use region server IP addresses to determine Internet access rather
than a generic address. Region server IP addresses may not be blocked
in the network construct. (bsc#1245305)
- Update version to 10.4.0
+ Remove repositories when the package is being removed
We do not want to leave repositories behind refering to the plugin that
is being removed when the package gets removed (bsc#1240310, bsc#1240311)
+ Turn docker into an optional setup (jsc#PCT-560)
Change the Requires into a Recommends and adapt the code accordingly
+ Support flexible licenses in GCE (jsc#PCT-531)
+ Drop the azure-addon package it is geting replaced by the
license-watcher package which has a generic implementation of the
same functionality.
+ Handle cache inconsistencies (bsc#1218345)
+ Properly handle the zypper root target argument (bsc#1240997)
- 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
- Update to 10.3.7 (bsc#1232770)
+ Fix the product triplet for LTSS, it is always SLES-LTSS, not
$BASEPRODUCT-LTSS
- Update to 10.3.6 (jsc#PCT-471, bsc#1230615)
+ Fix sudo setup
~ permissions cloudguestregistryauth
~ directory ownership /etc/sudoers.d
+ spec file
~ Remove traces of registry related entries on SLE 12
+ Forward port
~ fix-for-sles12-disable-registry.patch
~ fix-for-sles12-no-trans_update.patch
+ Deregister non free extensions at registercloudguest --clean
+ Fix registry cleanup at registercloudguest --clean, don't remove files
+ Prevent duplicate search entries in registry setup
- Update EC2 plugin to 1.0.5
+ Switch to using the region endpoint from IMDS to determine the region
instead of deriving the data from the availability zone
- Update to 10.3.5
+ Update spec file to build in all code streams,
SLE 12, SLE 15, ALP, and SLFO and have proper dependencies
- Update to 10.3.4
+ Modify the message when network access over a specific IP version does
not work. This is an informational message and should not look like
an error
+ Inform the user that LTSS registration takes a little longer
+ Add fix-for-sles12-no-trans_update.patch
+ SLE 12 family has no products with transactional-update we do not
need to look for this condition
- From 10.3.3 (bsc#1229472)
+ Handle changes in process structure to properly identify the running
zypper parent process and only check for 1 PID
- From 10.3.2
+ Remove rgnsrv-clnt-fix-docker-setup.patch included upstream
- From 10.3.1 (jsc#PCT-400)
+ Add support for LTSS registration
+ Add fix-for-sles12-disable-registry.patch
~ No container support in SLE 12
- Add rgnsrv-clnt-fix-docker-setup.patch (bsc#1229137)
+ The entry for the update infrastructure registry mirror was written
incorrectly causing docker daemon startup to fail.
- Update to version 10.3.0 (bsc#1227308, bsc#1222985)
+ Add support for sidecar registry
Podman and rootless Docker support to set up the necessary
configuration for the container engines to run as defined
+ Add running command as root through sudoers file
- Update to version 10.2.0 (bsc#1223571, bsc#1224014, bsc#1224016)
+ In addition to logging, write message to stderr when registration fails
+ Detect transactional-update system with read only setup and use
the transactional-update command to register
+ Handle operation in a different target root directory for credentials
checking
- Update to version 10.1.7 (bsc#1220164, bsc#1220165)
+ Fix the failover path to a new target update server. At present a new
server is not found since credential validation fails. We targeted
the server detected in down condition to verify the credentials instead
of the replacement server.
- Update EC2 plugin to 1.0.4 (bsc#1219156, bsc#1219159)
+ Fix the algorithm to determine the region from the availability zone
information retrieved from IMDS.
- Update to version 10.1.6
+ Support specifying an IPv6 address for a manually configured target
update server.
- Update to version 10.1.5 (bsc#1217583)
+ Fix fallback path when IPv6 network path is not usable
+ Enable an IPv6 fallback path in IMDS access if it cannot be accessed
over IPv4
+ Enable IMDS access over IPv6
- Update to version 10.1.4 (bsc#1217451)
+ Fetch cert for new update server during failover
Package avahi was updated:
- Add avahi-CVE-2024-52615.patch: Backport 4e2e1ea from upstream, Resolve fixed source ports for
wide-area DNS queries cause DNS responses be injected.
(CVE-2024-52615, bsc#1233421)
- Add avahi-CVE-2024-52616.patch:
Backporting 1dade81c from upstream: Properly randomize query id
of DNS packets.
(CVE-2024-52616, bsc#1233420)
- Add avahi-CVE-2023-38472.patch: Fix reachable assertion in
avahi_rdata_parse (bsc#1216853, CVE-2023-38472).
- Add avahi-CVE-2023-38470.patch: Ensure each label is at least one
byte long (bsc#1215947, CVE-2023-38470).
- Add avahi-CVE-2023-38471.patch: Extract host name usin
avahi_unescape_label (bsc#1216594, CVE-2023-38471).
- Add avahi-CVE-2023-38469.patch: Reject overly long TXT resource
records (bsc#1216598, CVE-2023-38469).
- Add avahi-CVE-2023-38473.patch: derive alternative host name from
its unescaped version (bsc#1216419 CVE-2023-38473).
Package libxml2 was updated:
- security update- added patches
https://gitlab.gnome.org/GNOME/libxml2/-/commit/852c93a2dc2224f020aab55a9702f992db404836
* libxml2-CVE-2025-9714-0.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/5153c7baceca65f575efdcbb0244860d97031f96
* libxml2-CVE-2025-9714-1.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/64115ed62dd01dab81a9157a54738523fe117333
* libxml2-CVE-2025-9714-2.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/2d97a97aa515f1bd3efc35c8ea2aa68676c6f8e1
* libxml2-CVE-2025-9714-3.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/012f8e92847a4e5ff684e7bd8e81a0b1ad104e32
* libxml2-CVE-2025-9714-4.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/949eced484520bdde3348e55eba048501b809127
* libxml2-CVE-2025-9714-5.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/390f05e7033fa8658f310dce9704f4f88e84b7fe
* libxml2-CVE-2025-9714-6.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/429d4ecaae5d61d591f279220125a583836fb84e
* libxml2-CVE-2025-9714-7.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/6f1470a5d6e3e369fe93f52d5760ba7c947f0cd1
* libxml2-CVE-2025-9714-8.patch
https://gitlab.gnome.org/GNOME/libxml2/-/commit/677a42645ef22b5a50741bad5facf9d8a8bc6d21
* libxml2-CVE-2025-9714.patch
- security update
- added patches
CVE-2025-8732 [bsc#1247850], infinite recursion in catalog parsing functions when processing malformed SGML catalog files
* libxml2-CVE-2025-8732.patch
- security update
- added patches
CVE-2025-7425 [bsc#1246296], Heap Use-After-Free in libxslt caused by atype corruption in xmlAttrPtr
+ libxml2-CVE-2025-7425.patch
- security update
- added patches
CVE-2025-49794 [bsc#1244554], heap use after free (UAF) can lead to Denial of service (DoS)
CVE-2025-49796 [bsc#1244557], type confusion may lead to Denial of service (DoS)
+ libxml2-CVE-2025-49794,49796.patch
- security update
- added patches
CVE-2025-6170 [bsc#1244700], stack buffer overflow may lead to a crash
CVE-2025-6021 [bsc#1244580], Integer Overflow in xmlBuildQName() Leads to Stack Buffer Overflow in libxml2
+ libxml2-CVE-2025-6170,6021.patch
- security update
- added patches
CVE-2025-32414 [bsc#1241551], out-of-bounds read when parsing text via the Python API
+ libxml2-CVE-2025-32414.patch
CVE-2025-32415 [bsc#1241453], a crafted XML document may lead to a heap-based buffer under-read
+ libxml2-CVE-2025-32415.patch
- 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
- Security fix (CVE-2024-34459, bsc#1224282) buffer over-read in
xmlHTMLPrintFileContext in xmllint.c
* Added libxml2-CVE-2024-34459.patch
- Security fix (CVE-2024-25062, bsc#1219576) use-after-free in XMLReader
* Added libxml2-CVE-2024-25062.patch
- Security update:
* [CVE-2023-45322, bsc#1216129] use-after-free in xmlUnlinkNode()
in tree.c
- Added file libxml2-CVE-2023-45322.patch
Package rsyslog was updated:
- fix rsyslog crash in imrelp (bsc#1210286) * add: 0001-Avoid-crash-on-restart-in-imrelp-SIGTTIN-handler.patch
Package python-requests was updated:
- Add CVE-2024-47081.patch upstream patch, fixes netrc credential leak (gh#psf/requests#6965, CVE-2024-47081, bsc#1244039)
- Update CVE-2024-35195.patch to allow the usage of "verify" parameter
as a directory, bsc#1225912
- Add CVE-2024-35195.patch (CVE-2024-35195, bsc#1224788)
- Add httpbin.patch to fix a test failure caused by the previous patch.
Package pam was updated:
- Make sure that the buffer containing encrypted passwords get's erased bedore free.
- Replace to previous CVE fix which led to CPU performance issues.
[bsc#1246221, CVE-2024-10041,
+ libpam-introduce-secure-memory-erasure-helpers.patch,
+ pam_modutil_get-overwrite-password-at-free.patch,
- passverify-always-run-the-helper-to-obtain-shadow_pwd.patch,
- pam_unix-arbitrary-upper-limit-for-MAX_FD_NO.patch]
- pam_unix: Set an arbitrary upper limit for the maximum file descriptor number
[pam_unix-arbitrary-upper-limit-for-MAX_FD_NO.patch, bsc#1246221]
- pam_namespace: convert functions that may operate on a user-controlled path
to operate on file descriptors instead of absolute path. And keep the
bind-mount protection from protect_mount() as a defense in depthmeasure.
[bsc#1244509
pam_inline-introduce-pam_asprintf-pam_snprintf-and-p.patch,
pam_namespace-fix-potential-privilege-escalation.patch,
pam_namespace-add-flags-to-indicate-path-safety.patch,
pam_namespace-secure_opendir-do-not-look-at-the-grou.patch]
- pam_namespace-fix-potential-privilege-escalation.patch adapted and includes
changes from upstream commits: ds6242a, bc856cd.
* pam_namespace fix logic in return value handling
* pam_namespace move functions around
- pam_env: Change the default to not read the user .pam_environment file
[bsc#1243226, CVE-2025-6018,
pam_env-change-the-default-to-not-read-the-user-env.patch]
- pam_unix/passverify: (get_account_info) [!HELPER_COMPILE]: Always return
PAM_UNIX_RUN_HELPER instead of trying to obtain the shadow password file
entry.
[passverify-always-run-the-helper-to-obtain-shadow-pwd.patch, bsc#1232234,
CVE-2024-10041]
- Do not reject the user with a hash assuming it's non-empty.
[pam_unix-allow-empty-passwords-with-non-empty-hashes.patch]
- Prevent cursor escape from the login prompt [bsc#1194818]
* Added: pam-bsc1194818-cursor-escape.patch
- Add missing O_DIRECTORY flag in `protect_dir()` for pam_namespace module.
[bsc#1218475, pam-bsc1218475-pam_namespace-O_DIRECTORY-flag.patch]
- pam_unix: Add no_pass_expiry option to ignore password expiration
[bsc#1215594 pam-unix-add-no_pass_expiry-option.patch]
Package yast2-network was updated:
- Honor the AutoYaST profile allowing to disable the IP check (bsc#1216859).
- 3.4.12
Package cpio was updated:
- Fix cpio not working after the fix in bsc#1218571, fixes bsc#1219238 * fix-bsc1219238.patch
- Fix CVE-2023-7207, path traversal vulnerability (bsc#1218571)
* fix-CVE-2023-7207.patch
Package pciutils was updated:
- pciutils.spec: Add a strict dependency to libpci. [bsc#1252338] Mixing different versions of pciutils and libpci could result in
a segmentation fault due to incompatible ABI.
- Apply "fix-lack-of-exposure-of-pci_init-for-libpci_3.2.patch" to
fix the biosdevname utility, which was broken by an update to
pcituils 3.5.x because the newer version forgot to export
pci_init() for library version LIBPCI_3.2. [bsc#1241994]
- Update to pciutils 3.5.6 from SLE-15 [jsc#PED-4587].
The following patches are obsolete in the newer version:
* add-decoding-of-vendor-specific-vpd-fields.patch
* pciutils-3.1.7-fix-memory-leak-in-get_cache_name.patch
* pciutils-3.5.1-add-support-for-32-bit-pci-domains.patch
* pciutils-lspci-Correct-Root-Capabilities-CRS-Software-Visibil.patch
* show-gen4-speed-properly.patch
- Add "pciutils-Add-PCIe-5.0-data-rate-32-GT-s-support.patch" and
"pciutils-Add-PCIe-6.0-data-rate-64-GT-s-support.patch" to fix
LnkCap speed recognition in lspci for multi PCIe ports such as
the ML110 Gen11. [bsc#1192862]
- Fix lspci outputs few of the VPD data fields are displayed as unknown (bsc#1170554, ltc#185587).
Added:
* pciutils-VPD-When-printing-item-IDs-escape-non-ASCII-characte.patch
* pciutils-VPD-Cleanup.patch
* pciutils-Add-decoding-of-vendor-specific-VPD-fields.patch
Package google-guest-oslogin was updated:
- Cherry-pick dont-retry-bad-requests.patch to stop retrying bad requests causing timeouts during container startup (bsc#1243992)
- 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)
- Fix file permissions for google_authorized_principals binary (bsc#1222171)
- Update to version 20240311.00 (bsc#1218548, bsc#1221900, bsc#1221901)
* pam: Bring back pam's account management implementation (#133)
* Change error messages when checking login policy (#129)
* Remove quintonamore from OWNERS (#128)
- Add explicit versioned dependency on google-guest-agent (bsc#1219642)
- Update to version 20231116.00
* build: Fix DESTDIR concatenation (#124)
- from version 20231113.00
* build: Fix clang build (#122)
- from version 20231103.00
* Update owners (#121)
- Update to version 20231101.00 (bsc#1216548, bsc#1216750)
* Fix HTTP calls retry logic (#117)
- Update to version 20231004
* packaging: Make the dependency explicit (#120)
- update to 20230926.00:
* fix suse build
* selinux: fix selinux build (#114)
* test: align CXX Flags
* sshca: Make the implementation more C++ like
* sshca: Add a SysLog wrapper
* oslogin_utils: introduce AuthorizeUser() API
* sshca: move it out of pam dir
* pam: start disabling the use of oslogin_sshca
* sshca: consider sshca API to assume a cert only
* authorized principals: introduce the new command
* authorize keys: update to use new APIs
* pam modules: remove pam_*_admin and update pam_*_login
* cache_refresh: should be catching by reference.
- Update to version 20230823.00
* selinux: Add sshd_key_t type enforcement to trusted user ca (#113)
- from version 20230822.00
* sshca: Add tests with fingerprint and multiple extensions (#111)
- from version 20230821.01
* sshca: Support method token and handle multi line (#109)
- from version 20230821.00
* Update owners (#110)
- Update to version 20230808.00
* byoid: extract and apply the ca fingerprint to policy call (#106)
- Update to version 20230502.00
* Improve the URL in 2fa prompt (#104)
- from version 20230406.02
* Check open files (#101)
- from version 20230406.01
* Initialize variables (#100)
* Fix formatting (#102)
- from version 20230406.00
* PAM cleanup: remove duplicates (#97)
- from version 20230405.00
* NSS cleanup (#98)
- from version 20230403.01
* Cleanup Makefiles (#95)
- from version 20230403.00
* Add anandadalton to the owners list (#96)
- Update to version 20230217.00
* Update OWNERS (#91)
- from version 20230202.00
* Update owners file (#89)
- Update to version 20220721.00 (bsc#1202100, bsc#1202101)
* prune outdated info from readme (#86)
- from version 20220714.00
* strip json-c version symbol (#84)
- from version 20220622.00
* pam login: split conditions for logging (#83)
- use pam_moduledir (boo#1191036)
* Support UsrMerge project
- Update to version 20220411.00
* pam login: split conditions for logging (#83)
Package pam-config was updated:
- Stop adding pam_env in AUTH stack, and be sure to put this module at the really end of the SESSION stack.
[bsc#1243226, CVE-2025-6018, remove-pam_env-from-auth-stack.patch]
Package python-urllib3 was updated:
- Add patch CVE-2025-50181-poolmanager-redirects.patch: * Pool managers now properly control redirects when retries is passed
(CVE-2025-50181, GHSA-pq67-6m6q-mj2v, bsc#1244925)
- Add CVE-2024-37891.patch (bsc#1226469, CVE-2024-37891)
- Add CVE-2023-45803.patch (bsc#1216377, CVE-2023-45803)
gh#urllib3/urllib3@4e98d57809da
Package wget was updated:
- Drop support for shorthand URLs * Breaking change to fix CVE-2024-10524.
[+ drop-support-for-shorthand-URLs.patch, bsc#1233773]
- If wget for an http URL is redirected to a different site (hostname
parts of URLs differ), then any "Authenticate" and "Cookie" header
entries are discarded.
[bsc#1185551, wget-do-not-propagate-credentials.patch,
bsc#1230795, CVE-2021-31879]
- Fix mishandled semicolons in the userinfo subcomponent could lead to an
insecure behavior in which data that was supposed to be in the userinfo
subcomponent is misinterpreted to be part of the host subcomponent.
[bsc#1226419, CVE-2024-38428, properly-re-implement-userinfo-parsing.patch]
- Fixed the failure to detect SSL handshake timeout
[bsc#1217717, wget-add-support-for-timeout-with-ssl.patch,
wget-gnutls-honor-connect-timeout.patch]
Package timezone was updated:
- Update to 2025b: * New zone for Aysén Region in Chile (America/Coyhaique) which
moves from -04/-03 to -03
- Refresh patches
* revert-philippines-historical-data.patch
* tzdata-china.diff
- 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
- update to 2024a:
* Kazakhstan unifies on UTC+5. This affects Asia/Almaty and
Asia/Qostanay which together represent the eastern portion of the
country that will transition from UTC+6 on 2024-03-01 at 00:00 to
join the western portion. (Thanks to Zhanbolat Raimbekov.)
* Palestine springs forward a week later than previously predicted
in 2024 and 2025. (Thanks to Heba Hamad.) Change spring-forward
predictions to the second Saturday after Ramadan, not the first;
this also affects other predictions starting in 2039.
* Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00
not 00:00. (Thanks to Äoà n Trần Công Danh.)
* From 1947 through 1949, Toronto's transitions occurred at 02:00
not 00:00. (Thanks to Chris Walton.)
* In 1911 Miquelon adopted standard time on June 15, not May 15.
* The FROM and TO columns of Rule lines can no longer be "minimum"
or an abbreviation of "minimum", because TZif files do not support
DST rules that extend into the indefinite past - although these
rules were supported when TZif files had only 32-bit data, this
stopped working when 64-bit TZif files were introduced in 1995.
This should not be a problem for realistic data, since DST was
first used in the 20th century. As a transition aid, FROM columns
like "minimum" are now diagnosed and then treated as if they were
the year 1900; this should suffice for TZif files on old systems
with only 32-bit time_t, and it is more compatible with bugs in
2023c-and-earlier localtime.c. (Problem reported by Yoshito
Umaoka.)
* localtime and related functions no longer mishandle some
timestamps that occur about 400 years after a switch to a time
zone with a DST schedule. In 2023d data this problem was visible
for some timestamps in November 2422, November 2822, etc. in
America/Ciudad_Juarez. (Problem reported by Gilmore Davidson.)
* strftime %s now uses tm_gmtoff if available. (Problem and draft
patch reported by Dag-Erling Smørgrav.)
* The strftime man page documents which struct tm members affect
which conversion specs, and that tzset is called. (Problems
reported by Robert Elz and Steve Summit.)
- update to 2023d:
* Ittoqqortoormiit, Greenland changes time zones on
2024-03-31.
* Vostok, Antarctica changed time zones on 2023-12-18.
* Casey, Antarctica changed time zones five times since
2020.
* Code and data fixes for Palestine timestamps starting in
2072.
* A new data file zonenow.tab for timestamps starting now.
* Fix predictions for DST transitions in Palestine in
2072-2075, correcting a typo introduced in 2023a.
* Vostok, Antarctica changed to +05 on 2023-12-18. It had
been at +07 (not +06) for years.
* Change data for Casey, Antarctica to agree with
timeanddate.com, by adding five time zone changes since 2020.
Casey is now at +08 instead of +11.
* Much of Greenland, represented by America/Nuuk, changed
its standard time from -03 to -02 on 2023-03-25, not on
2023-10-28.
* localtime.c no longer mishandles TZif files that contain
a single transition into a DST regime. Previously,
it incorrectly assumed DST was in effect before the transition
too.
* tzselect no longer creates temporary files.
* tzselect no longer mishandles the following:
* Spaces and most other special characters in BUGEMAIL,
PACKAGE, TZDIR, and VERSION.
* TZ strings when using mawk 1.4.3, which mishandles
regular expressions of the form /X{2,}/.
* ISO 6709 coordinates when using an awk that lacks the
GNU extension of newlines in -v option-arguments.
* Non UTF-8 locales when using an iconv command that
lacks the GNU //TRANSLIT extension.
* zic no longer mishandles data for Palestine after the
year 2075.
- Refresh tzdata-china.diff
Package ntp was updated:
Package libgcrypt was updated:
- Security fix [bsc#1221107, CVE-2024-2236] * Add --enable-marvin-workaround to spec to enable workaround
* Fix timing based side-channel in RSA implementation ( Marvin attack )
* Add libgcrypt-CVE-2024-2236_01.patch
* Add libgcrypt-CVE-2024-2236_02.patch
* Add libgcrypt-CVE-2024-2236_03.patch
* Add libgcrypt-CVE-2024-2236_04.patch
* Add libgcrypt-CVE-2024-2236_05.patch
* Add libgcrypt-CVE-2024-2236_06.patch
* Add libgcrypt-CVE-2024-2236_07.patch
* Add libgcrypt-CVE-2024-2236_08.patch
* Add libgcrypt-CVE-2024-2236_09.patch
* Add libgcrypt-CVE-2024-2236_10.patch
* Add libgcrypt-CVE-2024-2236_11.patch
* Add libgcrypt-CVE-2024-2236_decoding_fix.patch
Package libtasn1 was updated:
- Security fix: [bsc#1256341, CVE-2025-13151] * Stack-based buffer overflow. The function asn1_expend_octet_string()
fails to validate the size of input data resulting in a buffer overflow.
* Add libtasn1-CVE-2025-13151.patch
- 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 suse-module-tools was updated:
- Update to version 12.13: added blacklist entries in modprobe.conf * blacklist RNDIS modules (bsc#1205767, jsc#PED-5731, CVE-2023-23559)
* blacklist cls_tcindex module (bsc#1210335, CVE-2023-1829)
* blacklist isst_if_mbox_msr (bsc#1187196)
Package grep was updated:
- port-recent-fix-to-older-pcre-version.patch: Don't assume that a pcre_exec that returns PCRE_ERROR_NOMATCH leaves its sub
argument alone. (bsc#1227099)
Package krb5 was updated:
- Remove des3-cbc-sha1 and arcfour-hmac-md5 from permitted enctypes unless new special options "allow_des3" or "allow_rc4"
are set; (CVE-2025-3576); (bsc#1241219).
- Add patch 0018-prep-CVE-2025-3576.patch
- Add patch 0019-CVE-2025-3576.patch
- 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
- Fix vulnerabilities in GSS message token handling, add patch
0016-Fix-vulnerabilities-in-GSS-message-token-handling.patch
* CVE-2024-37370, bsc#1227186
* CVE-2024-37371, bsc#1227187
- Fix warning executing %postun scriptlet; (bsc#1223122);
- Fix memory leaks, add patch 0015-Fix-two-unlikely-memory-leaks.patch
* CVE-2024-26458, bsc#1220770
* CVE-2024-26461, bsc#1220771
- Update to krb5 1.16.3 (jsc#PED-7884). Most relevant changes:
* Remove the triple-DES and RC4 encryption types from the default
value of supported_enctypes, which determines the default key
and salt types for new password-derived keys. By default, keys
will only created only for AES128 and AES256. This mitigates
some types of password guessing attacks.
* Add support for the AES-SHA2 enctypes, which allows sites to
conform to Suite B crypto requirements.
- Removed patches, useless or upstreamed
* krb5-1.10-kpasswd_tcp.patch
* krb5-1.7-doublelog.patch
* krb5-1.9-kprop-mktemp.patch
* krb5-1.10-ksu-access.patch
* krb5-kvno-230379.patch
* krb5-1.12-doxygen.patch
* bnc#897874-CVE-2014-5351.diff
* krb5-1.13-work-around-replay-cache-creation-race.patch
* 0104-Verify-decoded-kadmin-C-strings-CVE-2015-8629.patch
* 0105-Fix-leaks-in-kadmin-server-stubs-CVE-2015-8631.patch
* 0106-Check-for-null-kadm5-policy-name-CVE-2015-8630.patch
* 0109-Preserve-GSS-context-on-init-accept-failure.patch
* 0115-Remove-incorrect-KDC-assertion.patch
* 0116-Implement-GSS_KRB5_CRED_NO_CI_FLAGS_X-cred-option.patch
* 0117-Add-tests-for-GSS_KRB5_CRED_NO_CI_FLAGS_X.patch
* 0118-Implement-GSS_KRB5_CRED_NO_CI_FLAGS_X-for-SPNEGO.patch
* 0119-Load-mechglue-config-files-from-etc-gss-mech.d.patch
* 0120-Document-etc-gss-mech.d-.conf.patch
* 0121-Fix-impersonate_name-to-work-with-interposers.patch
* 0122-Use-preauth-options-when-changing-password.patch
* 0123-Improve-extended-gic-option-support.patch
* 0124-Use-responder-for-non-preauth-AS-requests.patch
- New patches:
* 0011-Fix-KDC-null-deref-on-bad-encrypted-challenge.patch
* Fix KDC null pointer dereference via a FAST inner body that
lacks a server field; (CVE-2021-37750); (bsc#1189929);
0012-Fix-KDC-null-deref-on-TGS-inner-body-null-server.patch
- Renamed patches:
* Patch krb5-1.12-pam.patch -> 0001-krb5-1.12-pam.patch
* Patch krb5-1.9-manpaths.dif -> 0002-krb5-1.9-manpaths.patch
* Patch krb5-1.12-buildconf.patch -> 0003-krb5-1.12-buildconf.patch
* Patch krb5-1.6.3-gssapi_improve_errormessages.dif ->
0004-krb5-1.6.3-gssapi_improve_errormessages.patch
* Patch krb5-1.6.3-ktutil-manpage.dif ->
0005-krb5-1.6.3-ktutil-manpage.patch
* Patch krb5-1.12-api.patch -> 0006-krb5-1.12-api.patch
* Patch krb5-1.12-ksu-path.patch -> 0007-krb5-1.12-ksu-path.patch
* Patch krb5-1.12-selinux-label.patch -> 0008-krb5-1.12-selinux-label.patch
* Patch krb5-1.9-debuginfo.patch -> 0009-krb5-1.9-debuginfo.patch
* Patch 0125-Add-recursion-limit-for-ASN.1-indefinite-lengths.patch ->
0010-Add-recursion-limit-for-ASN.1-indefinite-lengths.patch
* Patch 0126-Fix-integer-overflows-in-PAC-parsing.patch ->
0013-Fix-integer-overflows-in-PAC-parsing.patch
* Patch 0127-Ensure-array-count-consistency-in-kadm5-RPC.patch ->
0014-Ensure-array-count-consistency-in-kadm5-RPC.patch
Package net-tools was updated:
- Drop old Fedora patch net-tools-1.60-interface_stack.patch. It provided a fix for CVE-2025-46836 (bsc#142461), but it was fixes
by the upstream in 2025 in a different way. Revert interferring
net-tools-CVE-2025-46836.patch back to the upstream version.
- Fix stack buffer overflow in parse_hex (bsc#1248687,
GHSA-h667-qrp8-gj58, net-tools-parse_hex-stack-overflow.patch).
- Fix stack-based buffer overflow in proc_gen_fmt (bsc#1248687,
GHSA-w7jq-cmw2-cq59,
net-tools-proc_gen_fmt-buffer-overflow.patch).
- Avoid unsafe memcpy in ifconfig (bsc#1248687,
net-tools-ifconfig-avoid-unsafe-memcpy.patch).
- Prevent overflow in ax25 and netrom (bsc#1248687,
net-tools-ax25+netrom-overflow-1.patch,
net-tools-ax25+netrom-overflow-2.patch).
- Keep possibility to enter long interface names, even if they are
not accepted by the kernel, because it was always possible up to
CVE-2025-46836 fix. But issue a warning about an interface name
concatenation (bsc#1248410,
net-tools-ifconfig-long-name-warning.patch).
- Provide more readable error for interface name size checking
introduced by net-tools-CVE-2025-46836.patch
(bsc#1243581, net-tools-CVE-2025-46836-error-reporting.patch).
- Fix a regression in net-tools-CVE-2025-46836.patch (bsc#1246608).
- Perform bound checks when parsing interface labels in
/proc/net/dev (bsc#1243581, CVE-2025-46836, GHSA-pfwf-h6m3-63wf,
net-tools-CVE-2025-46836.patch,
net-tools-CVE-2025-46836-regression.patch).
Package libzypp was updated:
- Do not double encode URL strings passed on the commandline (bsc#1237587)
URLs passed on the commandline must have their special chars
encoded already. We just want to check and encode forgotten
unsafe chars like a blank. A '%' however must not be encoded
again.
- version 16.22.16 (0)
- Url: queryparams without value should not have a trailing "=".
- version 16.22.15 (0)
- Url query part: `=` is a safe char in value (bsc#1234304)
Some CDN auth token implementations require a `=` within the
query parameters value not to be %-encoded.
- version 16.22.14 (0)
- Url: Hide known password entires when writing the query part
(bsc#1050625 bsc#1177583, CVE-2017-9271)
- version 16.22.13 (0)
- applydeltaprm: Create target directory if it does not exist
(bsc#1219442)
- version 16.22.12 (0)
- Touch /run/reboot-needed if a patch suggesting a reboot was
installed (bsc#1217948)
It is expected that /run is cleaned at boot time, so the presence
of the file is one way to indicate that the system needs a reboot.
The recommended way for scripts to test whether a system reboot
is suggested will be calling `zypper needs-rebooting`.
- version 16.22.11 (0)
- Ignore if the media to unmount is no longer mounted
(bsc#1216064)
- Close all media after having preloaded the cache.
Mitigates the change that during package installation e.g. a
nfs.service restart forcefully unmounts the media we access
(bsc#1216064)
- version 16.22.10 (0)
- repo: Don't download unneeded sqlite metadata (fixes #476)
- version 16.22.9 (0)
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)
- Add patch bsc1216825.patch
Avoid SIGSEGV in case of sending SIGTERM to a top command
running in batch mode (bsc#1216825)
Package zlib was updated:
- Fix CVE-2023-45853, integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_6, bsc#1216378
* CVE-2023-45853.patch
Package shadow was updated:
- bsc#916845 (CVE-2013-4235): Fix TOCTOU race condition Update shadow-CVE-2013-4235.patch to be more complete
- bsc#916845 (CVE-2013-4235): Fix TOCTOU race condition
Add shadow-CVE-2013-4235.patch
- bsc#1188307: Fix passwd segfault
Add shadow-bsc1188307-passwd-segfault.patch
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 libfastjson was updated:
- fix CVE-2020-12762 integer overflow and out-of-bounds write via a large JSON file (bsc#1171479)
add 0001-Fix-CVE-2020-12762.patch
Package python-pyOpenSSL was updated:
- Fix for bsc#1231700: * 0001-Don-t-use-things-after-they-re-freed.duh-709.patch: Add
missing patch that introduced X509._from_raw_x509_ptr needed by
CVE-2018-1000807 fix.
gh#pyca/pyopenssl@4aa52c33d3ee
- Add CVE-2018-1000807-8_use_after_free_X509.patch to fix
CVE-2018-1000807 (bsc#1111635) and CVE-2018-1000808 (bsc#1111634)
fix a memory leak and a potential UAF and also #722 (#723)
sanity check
bump cryptography minimum version, add changelog
- Add skip_user_after_free_tests.patch to pass the test suite.
- bsc#1021578 add move_cryptography_backend_import.patch to avoid bad
interaction with python-cryptography package.
Package openslp was updated:
- add separate source openslp.logrotate.systemd to use systemctl reload for logrotate configuration [bnc#1206153]
new file: openslp.logrotate.systemd
Package iputils was updated:
- Security fix [bsc#1243772, CVE-2025-48964] * Fix integer overflow in ping statistics via zero timestamp
* Add iputils-CVE-2025-48964_01.patch
* Add iputils-CVE-2025-48964_02.patch
- Security fix [bsc#1242300, CVE-2025-47268]
* integer overflow in RTT calculation can lead to undefined behavior
* Add iputils-CVE-2025-47268.patch
- Bring back ifenslave binary bcs#1234224
* Add iputils-ifenslave.diff
* Rebase iputils-disable-rarpd-rdisc.patch
- Resolve jsc#PED-9524
- Bump version to version s20161105 (bsc#1221439)
- This version can use ICMP datagram sockets without CAP_NET_RAW capabilites.
- Added iputils-disable-rarpd-rdisc.patch
- disables building of rarpd and rdisc as they're provided by separate package (rarpd) in SLE12-SP5
Full changelog:
* ping: eliminate deadcode & simplify
* ping: do not allow oversized packets to root
* correctly initialize first hop
* ping: fix ping -6 -I
* arping,doc: fix documentation of -I
* ping: fix error message when getting EACCES from connect()
* renamed INSTALL to INSTALL.md
* (re)structured INSTALL.md and transformed into markdown; added hint that installation into prefix has to be done with DESTDIR make variable and that there's no prefix support in configure, close #21
* ping: Silence GCC warnings when building with -fstrict-aliasing
* tftpd: Drop supplementary groups for root
* libgcrypt: fix static linking
* doc: Inserted a missing word
* tracepath6: avoid redundant family variable
* tracepath: borrow everything good from tracepath6
* tracepath: switch to dual-stack operation
* tracepath: remove now redundant tracepath6
* docs: fix parallel build of manpages
* ping: remove assignments of values that are never read
* docs: remove references to ping6 and traceroute6
* ping: work with older kernels that don't support ping sockets
* Revert "ping_common.c: fix message flood when EPERM is encountered in ping"
* reorder -I option parsing (boo#1057664)
* ping: also bind the ICMP socket to the specific device
- tracepath6 is now symlink to tracepath.
- Add fix for ICMP datagram socket ping6-Fix-device-binding.patch
(bsc#1196840, bsc#1199918, bsc#1199926, bsc#1199927).
- Remove 2 old patches (iputils-sec-ping-unblock.diff, iputils-ping-interrupt.diff)
Although not documented, they both belong to bsc#674304. Fix from 2011 was
resolved upstream in commit 810dd7f ("ping,ping6: Unmask signals on
start-up.") [1], released in s20121112.
- Update iputils-remove-bogus-check-required-for-2.4.9-kernels.patch
(backport 4471ac6 to add changes in header files)
- Use git format for iputils-ping-fix-pmtu-for-ipv6.patch (required by
%autosetup -p1)
- Use %autosetup -p1
- Backport license information from upstream (bnc#1082788):
iputils-add-license-info.diff
- Backport iputils-ping-fix-pmtu-for-ipv6.patch from upstream
to fix PMTU discovery in ping6. (bsc#1072460)
- Install rdisc as rdisc, do not use in.rdisc anymore (xinetd which
was using in.* names is obsolete anyways)
- iputils: remove man pages of unused binaries: ninfod, pg3, rdisc
(rdisc is in a separate package)
- Add systemd service for rarpd
- mark ping also verify not caps, as these are changed by the
permissions package. (bsc#1065835)
- Reintroduce rarpd as subpackage
- Explicitly list content in filelist as we have two subpackages
now
- Cleanup with spec-cleaner
- Update to version s20161105 (Changes taken from the RELNOTES file)
* ping: eliminate deadcode & simplify
* ping: do not allow oversized packets to root
* correctly initialize first hop
* ping: fix ping -6 -I
* arping,doc: fix documentation of -I
* ping: fix error message when getting EACCES from connect()
* renamed INSTALL to INSTALL.md
* (re)structured INSTALL.md and transformed into markdown; added hint that installation into prefix has to be done with DESTDIR make variable and that there's no prefix support in configure, close #21
* ping: Silence GCC warnings when building with -fstrict-aliasing
* tftpd: Drop supplementary groups for root
* libgcrypt: fix static linking
* doc: Inserted a missing word
* tracepath6: avoid redundant family variable
* tracepath: borrow everything good from tracepath6
* tracepath: switch to dual-stack operation
* tracepath: remove now redundant tracepath6
* docs: fix parallel build of manpages
* ping: remove assignments of values that are never read
* docs: remove references to ping6 and traceroute6
* ping: work with older kernels that don't support ping sockets
* Revert "ping_common.c: fix message flood when EPERM is encountered in ping"
* reorder -I option parsing (boo#1057664)
* ping: also bind the ICMP socket to the specific device
- tracepath6 is now symlink to tracepath.
- Add ping6 symlink (boo#1017616)
- do not install rarpd and rarpd.8 manpage (comes from rarpd rpm currently)
- Update to version s20160308 (Changes taken from the RELNOTES file)
* use syntax compatible with busybox date in Makefile
* 'admin prohibited' should print !X not !S.
* Makefile: use #define as in previous code changes
* doc/Makefile: require bash, because we use pushd and popd
* doc: don't timestamp manpages by default
* ping: status() now returns received/transmitted instead of trans/recv
* ping: don't mess with internals of struct msghdr
* ping: ICMP error replies while errno < 0 is a hard error
* ping: always use POSIX locale when parsing -i
* ping: link against libm
* made ping functions protocol independent
* ping: perform dual-stack ping by default
* ping: remove obsolete preprocessor directives
* ping: avoid name clashes between IPv4 and IPv6 code
* ping: merge all ping header files into a single one
* ping: merge `ping6` command into `ping`
* ping: refactor ping options
* ping: refactor ping socket code
* ping: merge IPv4 and IPv6 `pr_addr()`
* ping: fix defines and libs in Makefile
* ping: handle single protocol systems
* iputils ping/ping6: Add a function to check if a packet is ours
* ping: Add <linux/types.h> to fix compilation error.
* ping6: Use GNUTLS API directly for MD5. (v2)
* ping6: Use libgcrypt instead of gnutls for MD5.
* Allow ping to use IPv6 addresses
* ping,ping6 doc: More description on CAP_NET_RAW usage.
* if IPv4 resolving fails fallback to ping6
* ping: in usage print the 'ping -6' options as well
* ping: allow option -4 which forces IPv4
* combine sock and errno into a single structure
* This patch allows running ping and ping6 without root privileges on
* use better names for socket variables
* tracepath,doc: fix corrupted tag
* doc: ping: add missing options and remove ping6
* ninfod: remove unused variables
* ninfod: Regenerate configure by autoconf-2.69.
* ninfod: libgcrypt support.
* Fix building with musl
* travis.yml: install nettle-dev
* Allow using nettle instead of libgcrypt for MD5
* avoid compiler warning caused by snapshot.h
* make `getaddrinfo()` and `getnameinfo()` usage consistent
* enable IDN by default
* remove IPV4_TARGETS and IPV6_TARGETS
* Use svg instead of png to get better image quality
* spec: Configure before building ninfod.
* spec: Fix date in %changelog.
* make,spec: Add rpm target.
- Refreshed patches
* iputils-ping-interrupt.diff
* iputils-sec-ping-unblock.diff
- Remove ifenslave.c. It has been removed in the linux kernel commit
b1098bbe1b24("bonding: remove ifenslave.c from kernel source").
bonding can be done via iproute (netlink)
- dropped iputils-ifenslave.diff
- Append our CFLAGS to the upstream ones instead of overriding them.
- Cleanup old make command since the upstream Makefile does things right
it seems.
- Use Provides: for old /{,s}bin utils to satisfy reverse dependencies.
- Install utilities to /bin and /sbin until reverse dependencies are
properly fixed.
- Do not install tftp and traceroute to avoid conflicts with the tftp and
traceroute packages. Stick to what iputils used to provide in the past.
- Remove iputils-traceroute6-stdint.diff patch since we are not building
the traceroute* utilities.
- Install tracepath to /usr/bin. (boo#795788)
- Update to version s20150815
* use syntax compatible with busybox date in Makefile
* Makefile: use #define as in previous code changes
* ping: status() now returns received/transmitted instead of trans/recv
* ping: don't mess with internals of struct msghdr
* tracepath,doc: fix corrupted tag
* made ping functions protocol independent
* Allow ping to use IPv6 addresses
* if IPv4 resolving fails fallback to ping6
* ping: in usage print the 'ping -6' options as well
* ping: allow option -4 which forces IPv4
* combine sock and errno into a single structure
* This patch allows running ping and ping6 without root privileges on
* use better names for socket variables
* travis.yml: install nettle-dev
* Allow using nettle instead of libgcrypt for MD5
* avoid compiler warning caused by snapshot.h
* make `getaddrinfo()` and `getnameinfo()` usage consistent
* enable IDN by default
* ping: perform dual-stack ping by default
* remove IPV4_TARGETS and IPV6_TARGETS
* ping: remove obsolete preprocessor directives
* ping: avoid name clashes between IPv4 and IPv6 code
* ping: merge all ping header files into a single one
* ping: merge `ping6` command into `ping`
* ping: refactor ping options
* ping: refactor ping socket code
* ping: merge IPv4 and IPv6 `pr_addr()`
* Use svg instead of png to get better image quality
* iputils ping/ping6: Add a function to check if a packet is ours
* ping: Add <linux/types.h> to fix compilation error.
* ping6: Use GNUTLS API directly for MD5. (v2)
* ping6: Use libgcrypt instead of gnutls for MD5.
* ninfod: Regenerate configure by autoconf-2.69.
* ninfod: libgcrypt support.
* spec: Configure before building ninfod.
* spec: Fix date in %changelog.
* make,spec: Add rpm target.
* ping,ping6 doc: More description on CAP_NET_RAW usage.
- Update patches
* iputils-s20101006-ping-interrupt.diff > iputils-ping-interrupt.diff
* iputils-s20101006-sec-ping-unblock.diff > iputils-sec-ping-unblock.diff
* iputils-remove-bogus-check-required-for-2.4.9-kernels.patch
- Update home project page and download Url
- Remove obsolete %clean section
- Remove UsrMerge process; it has been done for more than two
openSUSE releases now
- Fix a bogus kernel version check (boo#927831):
iputils-remove-bogus-check-required-for-2.4.9-kernels.patch
Package vim was updated:
- Fix for bsc#1229750.- nocompatible must be set before the syntax highlighting is turned on.
- Fix the following CVEs and bugs:
* bsc#1246602 (CVE-2025-53906)
* bsc#1246604 (CVE-2025-53905)
* bsc#1247939 (CVE-2025-55158)
* bsc#1247938 (CVE-2025-55157)
- Update to 9.1.1629:
9.1.1629: Vim9: Not able to use more than 10 type arguments in a generic function
9.1.1628: fuzzy.c has a few issues
9.1.1627: fuzzy matching can be improved
9.1.1626: cindent: does not handle compound literals
9.1.1625: Autocompletion slow with include- and tag-completion
9.1.1624: Cscope not enabled on MacOS
9.1.1623: Buffer menu does not handle unicode names correctly
9.1.1622: Patch v9.1.1432 causes performance regressions
9.1.1621: flicker in popup menu during cmdline autocompletion
9.1.1620: filetype: composer.lock and symfony.lock files not recognized
9.1.1619: Incorrect E535 error message
9.1.1618: completion: incorrect selected index returned from complete_info()
9.1.1617: Vim9: some error messages can be improved
9.1.1616: xxd: possible buffer overflow with bitwise output
9.1.1615: diff format erroneously detected
9.1.1614: Vim9: possible variable type change
9.1.1613: tests: test_search leaves a few swapfiles behind
9.1.1612: Ctrl-G/Ctrl-T do not ignore the end search delimiter
9.1.1611: possible undefined behaviour in mb_decompose()
9.1.1610: completion: hang or E684 when 'tagfunc' calls complete()
9.1.1609: complete: Heap-buffer overflow with complete function
9.1.1608: No command-line completion for :unsilent {command}
9.1.1607: :apple command detected as :append
9.1.1606: filetype: a few more files are not recognized
9.1.1605: cannot specify scope for chdir()
9.1.1604: completion: incsearch highlight might be lost
9.1.1603: completion: cannot use autoloaded funcs in 'complete' F{func}
9.1.1602: filetype: requirements-*.txt files are not recognized
9.1.1601: Patch v8.1.0425 was wrong
9.1.1600: using diff anchors with hidden buffers fails silently
9.1.1599: :bnext doesn't go to unlisted help buffers
9.1.1598: filetype: waybar config file is not recognized
9.1.1597: CI reports leaks in libgtk3 library
9.1.1596: tests: Test_search_wildmenu_iminsert() depends on help file
9.1.1595: Wayland: non-portable use of select()
9.1.1594: completion: search completion throws errors
9.1.1593: Confusing error when compiling incomplete try block
9.1.1592: Vim9: crash with classes and garbage collection
9.1.1591: VMS support can be improved
9.1.1590: cannot perform autocompletion
9.1.1589: Cannot disable cscope interface using configure
9.1.1588: Vim9: cannot split dict inside command block
9.1.1587: Wayland: timeout not updated before select()
9.1.1586: Vim9: can define an enum/interface in a function
9.1.1585: Wayland: gvim still needs GVIM_ENABLE_WAYLAND
9.1.1584: using ints as boolean type
9.1.1583: gvim window lost its icons
9.1.1582: style issue in vim9type.c and vim9generics.c
9.1.1581: possible memory leak in vim9generics.c
9.1.1580: possible memory leak in vim9type.c
9.1.1579: Coverity complains about unchecked return value
9.1.1578: configure: comment still mentions autoconf 2.71
9.1.1577: Vim9: no generic support yet
9.1.1576: cannot easily trigger wildcard expansion
9.1.1575: tabpanel not drawn correctly with wrapped lines
9.1.1574: Dead code in mbyte.c
9.1.1573: Memory leak when pressing Ctrl-D in cmdline mode
9.1.1572: expanding $var does not escape whitespace for 'path'
9.1.1571: CmdlineChanged triggered to often
9.1.1570: Copilot suggested some improvements in cmdexpand.c
9.1.1569: tests: Vim9 tests can be improved
9.1.1568: need a few more default highlight groups
9.1.1567: crash when using inline diff mode
9.1.1566: self-referenced enum may not get freed
9.1.1565: configure: does not consider tiny version for wayland
9.1.1564: crash when opening popup to closing buffer
9.1.1563: completion: ruler may disappear
9.1.1562: close button always visible in the 'tabline'
9.1.1561: configure: wayland test can be improved
9.1.1560: configure: uses $PKG_CONFIG before it is defined
9.1.1559: tests: Test_popup_complete_info_01() fails when run alone
9.1.1558: str2blob() treats NULL string and empty string differently
9.1.1557: not possible to anchor specific lines in difff mode
9.1.1556: string handling in cmdexpand.c can be improved
9.1.1555: completion: repeated insertion of leader
9.1.1554: crash when omni-completion opens command-line window
9.1.1553: Vim9: crash when accessing a variable in if condition
9.1.1552: [security]: path traversal issue in tar.vim
9.1.1551: [security]: path traversal issue in zip.vim
9.1.1550: defaults: 'showcmd' is not enabled in non-compatible mode on Unix
9.1.1549: filetype: pkl files are not recognized
9.1.1548: filetype: OpenFGA files are not recognized
9.1.1547: Wayland: missing ifdef
9.1.1546: Vim9: error with has() and short circuit evaluation
9.1.1545: typo in os_unix.c
9.1.1544: :retab cannot be limited to indentation only
9.1.1543: Wayland: clipboard appears to not be working
9.1.1542: Coverity complains about uninitialized variable
9.1.1541: Vim9: error when last enum value ends with a comma
9.1.1540: completion: menu state wrong on interruption
9.1.1539: completion: messages don't respect 'shm' setting
9.1.1537: helptoc: still some issues when markdown code blocks
9.1.1536: tests: test_plugin_comment uses wrong :Check command
9.1.1535: the maximum search count uses hard-coded value 99
9.1.1534: unnecessary code in tabpanel.c
9.1.1533: helptoc: does not handle code sections in markdown well
9.1.1532: termdebug: not enough ways to configure breakpoints
9.1.1531: confusing error with nested legacy function
9.1.1530: Missing version change in v9.1.1529
9.1.1529: Win32: the toolbar in the GUI is old and dated
9.1.1528: completion: crash with getcompletion()
9.1.1527: Vim9: Crash with string compound assignment
9.1.1526: completion: search completion match may differ in case
9.1.1525: tests: testdir/ is a bit messy
9.1.1524: tests: too many imports in the test suite
9.1.1523: tests: test_clipmethod fails in non X11 environment
9.1.1522: tests: still some ANSI escape sequences in test output
9.1.1521: completion: pum does not reset scroll pos on reopen with 'noselect'
9.1.1520: completion: search completion doesn't handle 'smartcase' well
9.1.1519: tests: Test_termdebug_decimal_breakpoints() may fail
9.1.1518: getcompletiontype() may crash
9.1.1517: filetype: autopkgtest files are not recognized
9.1.1516: tests: no test that 'incsearch' is updated after search completion
9.1.1515: Coverity complains about potential unterminated strings
9.1.1514: Coverity complains about the use of tmpfile()
9.1.1513: resizing Vim window causes unexpected internal window width
9.1.1512: completion: can only complete from keyword characters
9.1.1511: tests: two edit tests change v:testing from 1 to 0
9.1.1510: Search completion may use invalid memory
9.1.1509: patch 9.1.1505 was not good
9.1.1508: string manipulation can be improved in cmdexpand.c
9.1.1507: symlinks are resolved on :cd commands
9.1.1506: tests: missing cleanup in Test_search_cmdline_incsearch_highlight()
9.1.1505: not possible to return completion type for :ex command
9.1.1504: filetype: numbat files are not recognized
9.1.1503: filetype: haxe files are not recognized
9.1.1502: filetype: quickbms files are not recognized
9.1.1501: filetype: flix files are not recognized
9.1.1500: if_python: typo in python error variable
9.1.1499: MS-Windows: no indication of ARM64 architecture
9.1.1498: completion: 'complete' funcs behave different to 'omnifunc'
9.1.1497: Link error with shm_open()
9.1.1496: terminal: still not highlighting empty cells correctly
9.1.1495: Wayland: uses $XDG_SEAT to determine seat
9.1.1494: runtime(tutor): no French translation for Chapter 2
9.1.1493: manually comparing positions on buffer
9.1.1492: tests: failure when Wayland compositor fails to start
9.1.1491: missing out-of-memory checks in cmdexpand.c
9.1.1490: 'wildchar' does not work in search contexts
9.1.1489: terminal: no visual highlight of empty cols with empty 'listchars'
9.1.1488: configure: using obsolete macro AC_PROG_GCC_TRADITIONAL
9.1.1487: :cl doesn't invoke :clist
9.1.1486: documentation issues with Wayland
9.1.1485: missing Wayland clipboard support
9.1.1484: tests: Turkish locale tests fails on Mac
9.1.1483: not possible to translation position in buffer
9.1.1482: scrolling with 'splitkeep' and line()
9.1.1481: gcc complains about uninitialized variable
9.1.1480: Turkish translation outdated
9.1.1479: regression when displaying localized percentage position
9.1.1478: Unused assignment in ex_uniq()
9.1.1476: no easy way to deduplicate text
9.1.1476: missing out-of-memory checks in cmdexpand.c
9.1.1475: completion: regression when "nearest" in 'completeopt'
9.1.1474: missing out-of-memory check in mark.c
9.1.1473: inconsistent range arg for :diffget/diffput
9.1.1472: if_python: PySequence_Fast_{GET_SIZE,GET_ITEM} removed
9.1.1471: completion: inconsistent ordering with CTRL-P
9.1.1470: use-after-free with popup callback on error
9.1.1469: potential buffer-underflow with invalid hl_id
9.1.1468: filetype: bright(er)script files are not recognized
9.1.1467: too many strlen() calls
9.1.1466: filetype: not all lex files are recognized
9.1.1465: tabpanel: not correctly drawn with 'equalalways'
9.1.1464: gv does not work in operator-pending mode
9.1.1463: Integer overflow in getmarklist() after linewise operation
9.1.1462: missing change from patch v9.1.1461
9.1.1461: tabpanel: tabpanel vanishes with popup menu
9.1.1460: MS-Windows: too many strlen() calls in os_win32.c
9.1.1459: xxd: coloring output is inefficient
9.1.1458: tabpanel: tabs not properly updated with 'stpl'
9.1.1457: compile warning with tabpanelopt
9.1.1456: comment plugin fails toggling if 'cms' contains \
9.1.1455: Haiku: dailog objects created with no reference
9.1.1454: tests: no test for pum at line break position
9.1.1453: tests: Test_geometry() may fail
9.1.1452: completion: redundant check for completion flags
9.1.1451: tabpanel rendering artifacts when scrolling
9.1.1450: Session has wrong arglist with :tcd and :arglocal
9.1.1449: typo in pum_display()
9.1.1448: tabpanel is not displayed correctly when msg_scrolled
9.1.1447: completion: crash when backspacing with fuzzy completion
9.1.1446: filetype: cuda-gdb config files are not recognized
9.1.1445: negative matchfuzzy scores although there is a match
9.1.1444: Unused assignment in set_fuzzy_score()
9.1.1443: potential buffer underflow in insertchar()
9.1.1442: tests: Test_diff_fold_redraw() is insufficient
9.1.1441: completion: code can be improved
9.1.1440: too many strlen() calls in os_win32.c
9.1.1439: Last diff folds not merged
9.1.1438: tests: Test_breakindent_list_split() fails
9.1.1437: MS-Windows: internal compile error in uc_list()
9.1.1436: GUI control code is displayed on the console on startup
9.1.1435: completion: various flaws in fuzzy completion
9.1.1434: MS-Windows: missing out-of-memory checks in os_win32.c
9.1.1433: Unnecessary :if when writing session
9.1.1432: GTK GUI: Buffer menu does not handle unicode correctly
9.1.1431: Hit-Enter Prompt when loading session files
9.1.1430: tabpanel may flicker in the GUI
9.1.1429: dragging outside the tabpanel changes tabpagenr
9.1.1428: completion: register completion needs cleanup
9.1.1427: rendering artifacts with the tabpanel
9.1.1426: completion: register contents not completed
9.1.1425: tabpanel: there are still some problems with the tabpanel
9.1.1424: PMenu selection broken with multi-line selection and limits
9.1.1423: :tag command not working correctly using Vim9 Script
9.1.1422: scheduling of complete function can be improved
9.1.1421: tests: need a test for the new-style tutor.tutor
9.1.1420: tests: could need some more tests for shebang lines
9.1.1419: It is difficult to ignore all but some events
9.1.1418: configures GUI auto detection favors GTK2
9.1.1417: missing info about register completion in complete_info()
9.1.1416: completion limits not respected for fuzzy completions
9.1.1415: potential use-after free when there is an error in 'tabpanel'
9.1.1414: MS-Windows: compile warnings in os_win32.c
9.1.1413: spurious CursorHold triggered in GUI on startup
9.1.1412: tests: Test_tabpanel_tabonly() fails on larger screens
9.1.1411: crash when calling non-existing function for tabpanel
9.1.1410: out-of-bounds access with 'completefunc'
9.1.1409: using f-flag in 'complete' conflicts with Neovim
9.1.1408: not easily possible to complete from register content
9.1.1407: Can't use getpos('v') in OptionSet when using setbufvar()
- Fix bsc#1228776 / CVE-2024-41965.
- Fix bsc#1239602 / CVE-2025-29768.
- Refresh patch:
vim-7.3-sh_is_bash.patch
- Update to 9.1.1406:
9.1.1406: crash when importing invalid tuple
9.1.1405: tests: no test for mapping with special keys in session file
9.1.1404: wrong link to Chapter 2 in new-tutor
9.1.1403: expansion of 'tabpanelopt' value adds wrong values
9.1.1402: multi-byte mappings not properly stored in session file
9.1.1401: list not materialized in prop_list()
9.1.1400: [security]: use-after-free when evaluating tuple fails
9.1.1399: tests: test_codestyle fails for auto-generated files
9.1.1398: completion: trunc does not follow Pmenu highlighting attributes
9.1.1397: tabpanel not correctly updated on :tabonly
9.1.1396: 'errorformat' is a global option
9.1.1395: search_stat not reset when pattern differs in case
9.1.1394: tabpanel not correctly redrawn on tabonly
9.1.1393: missing test for switching buffers and reusing curbuf
9.1.1392: missing patch number
9.1.1391: Vim does not have a vertical tabpanel
9.1.1390: style: more wrong indentation
9.1.1389: completion: still some issue when 'isexpand' contains a space
9.1.1388: Scrolling one line too far with 'nosmoothscroll' page scrolling
9.1.1387: memory leak when buflist_new() fails to reuse curbuf
9.1.1386: MS-Windows: some minor problems building on AARCH64
9.1.1385: inefficient loop for 'nosmoothscroll' scrolling
9.1.1384: still some problem with the new tutors filetype plugin
9.1.1383: completion: 'isexpand' option does not handle space char correct
9.1.1382: if_ruby: unused compiler warnings from ruby internals
9.1.1381: completion: cannot return to original text
9.1.1380: 'eventignorewin' only checked for current buffer
9.1.1379: MS-Windows: error when running evim when space in path
9.1.1378: sign without text overwrites number option
9.1.1377: patch v9.1.1370 causes some GTK warning messages
9.1.1376: quickfix dummy buffer may remain as dummy buffer
9.1.1375: [security]: possible heap UAF with quickfix dummy buffer
9.1.1374: completion: 'smartcase' not respected when filtering matches
9.1.1373: 'completeopt' checking logic can be simplified
9.1.1372: style: braces issues in various files
9.1.1371: style: indentation and brace issues in insexpand.c
9.1.1370: CI Tests favor GTK2 over GTK3
9.1.1369: configure still using autoconf 2.71
9.1.1368: GTK3 and GTK4 will drop numeric cursor support.
9.1.1367: too many strlen() calls in gui.c
9.1.1366: v9.1.1364 unintentionally changed sign.c and sound.c
9.1.1365: MS-Windows: compile warnings and too many strlen() calls
9.1.1364: style: more indentation issues
9.1.1363: style: inconsistent indentation in various files
9.1.1362: Vim9: type ignored when adding tuple to instance list var
9.1.1361: [security]: possible use-after-free when closing a buffer
9.1.1360: filetype: GNU Radio companion files are not recognized
9.1.1359: filetype: GNU Radio config files are not recognized
9.1.1358: if_lua: compile warnings with gcc15
9.1.1357: Vim incorrectly escapes tags with "[" in a help buffer
9.1.1356: Vim9: crash when unletting variable
9.1.1355: The pum_redraw() function is too complex
9.1.1354: tests: Test_terminalwinscroll_topline() fails on Windows
9.1.1353: missing change from v9.1.1350
9.1.1352: style: inconsistent indent in insexpand.c
9.1.1351: Return value of getcmdline() inconsistent in CmdlineLeavePre
9.1.1350: tests: typo in Test_CmdlineLeavePre_cabbr()
9.1.1349: CmdlineLeavePre may trigger twice
9.1.1348: still E315 with the terminal feature
9.1.1347: small problems with gui_w32.c
9.1.1346: missing out-of-memory check in textformat.c
9.1.1345: tests: Test_xxd_color2() test failure dump diff is misleading
9.1.1344: double free in f_complete_match() (after v9.1.1341)
9.1.1343: filetype: IPython files are not recognized
9.1.1342: Shebang filetype detection can be improved
9.1.1341: cannot define completion triggers
9.1.1340: cannot complete :filetype arguments
9.1.1339: missing out-of-memory checks for enc_to_utf16()/utf16_to_enc()
9.1.1338: Calling expand() interferes with cmdcomplete_info()
9.1.1337: Undo corrupted with 'completeopt' "preinsert" when switching buffer
9.1.1336: comment plugin does not support case-insensitive 'commentstring'
9.1.1335: Coverity complains about Null pointer dereferences
9.1.1334: Coverity complains about unchecked return value
9.1.1333: Coverity: complains about unutilized variable
9.1.1332: Vim9: segfault when using super within a lambda
9.1.1331: Leaking memory with cmdcomplete()
9.1.1330: may receive E315 in terminal
9.1.1329: cannot get information about command line completion
9.1.1328: too many strlen() calls in indent.c
9.1.1327: filetype: nroff detection can be improved
9.1.1326: invalid cursor position after 'tagfunc'
9.1.1325: tests: not checking error numbers properly
9.1.1324: undefined behaviour if X11 connection dies
9.1.1323: b:undo_ftplugin not executed when re-using buffer
9.1.1322: small delete register cannot paste multi-line correctly
9.1.1321: filetype: MS ixx and mpp files are not recognized
9.1.1320: filetype: alsoft config files are not recognized
9.1.1319: Various typos in the code, issue with test_inst_complete.vim
9.1.1318: tests: test_format fails
9.1.1317: noisy error when restoring folds from session fails
9.1.1316: missing memory allocation failure in os_mswin.c
9.1.1315: completion: issue with fuzzy completion and 'completefuzzycollect'
9.1.1314: max allowed string width too small
9.1.1313: compile warning about uninitialized value
9.1.1312: tests: Test_backupskip() fails when HOME is defined
9.1.1311: completion: not possible to limit number of matches
9.1.1310: completion: redundant check for preinsert effect
9.1.1309: tests: no test for 'pummaxwidth' with non-truncated "kind"
9.1.1308: completion: cannot order matches by distance to cursor
9.1.1307: make syntax does not reliably detect different flavors
9.1.1306: completion menu rendering can be improved
9.1.1305: completion menu active after switching windows/tabs
9.1.1304: filetype: some man files are not recognized
9.1.1303: missing out-of-memory check in linematch.c
9.1.1302: Coverity warns about using uninitialized value
9.1.1301: completion: cannot configure completion functions with 'complete'
9.1.1300: wrong detection of -inf
9.1.1299: filetype: mbsyncrc files are not recognized
9.1.1298: define_function() is too long
9.1.1297: Ctrl-D scrolling can get stuck
9.1.1296: completion: incorrect truncation logic
9.1.1295: clientserver: does not handle :stopinsert correctly
9.1.1294: gui tabline menu does not use confirm when closing tabs
9.1.1293: comment plugin does not handle 'exclusive' selection for comment object
9.1.1292: statusline not correctly evaluated
9.1.1291: too many strlen() calls in buffer.c
9.1.1290: tests: missing cleanup in test_filetype.vim
9.1.1289: tests: no test for matchparen plugin with WinScrolled event
9.1.1288: Using wrong window in ll_resize_stack()
9.1.1287: quickfix code can be further improved
9.1.1286: filetype: help files not detected when 'iskeyword' includes ":"
9.1.1285: Vim9: no error message for missing method after "super."
9.1.1284: not possible to configure pum truncation char
9.1.1283: quickfix stack is limited to 10 items
9.1.1282: Build and test failure without job feature
9.1.1281: extra newline output when editing stdin
9.1.1280: trailing additional semicolon in get_matches_in_str()
9.1.1279: Vim9: null_object and null_class are no reserved names
9.1.1278: Vim9: too long functions in vim9type.c
9.1.1277: tests: trailing comment char in test_popupwin
9.1.1276: inline word diff treats multibyte chars as word char
9.1.1275: MS-Windows: Not possible to pass additional flags to Make_mvc
9.1.1274: Vim9: no support for object<type> as variable type
9.1.1273: Coverity warns about using uninitialized value
9.1.1272: completion: in keyword completion Ctrl_P cannot go back after Ctrl_N
9.1.1271: filetype: Power Query files are not recognized
9.1.1270: missing out-of-memory checks in buffer.c
9.1.1269: completion: compl_shown_match is updated when starting keyword completion
9.1.1268: filetype: dax files are not recognized
9.1.1267: Vim9: no support for type list/dict<object<any>>
9.1.1266: MS-Windows: type conversion warnings
9.1.1265: tests: no tests for typing normal char during completion
9.1.1264: Vim9: error when comparing objects
9.1.1263: string length wrong in get_last_inserted_save()
9.1.1262: heap-buffer-overflow with narrow 'pummaxwidth' value
9.1.1261: No test for 'pummaxwidth' non-truncated items
9.1.1260: Hang when filtering buffer with NUL bytes
9.1.1259: some issues with comment package and tailing spaces
9.1.1258: regexp: max \U and \%U value is limited by INT_MAX
9.1.1257: Mixing vim_strsize() with mb_ptr2cells() in pum_redraw()
9.1.1256: if_python: duplicate tuple data entries
9.1.1255: missing test condition for 'pummaxwidth' setting
9.1.1254: need more tests for the comment plugin
9.1.1253: abort when closing window with attached quickfix data
9.1.1252: typos in code and docs related to 'diffopt' "inline:"
9.1.1251: if_python: build error with tuples and dynamic python
9.1.1250: cannot set the maximum popup menu width
9.1.1249: tests: no test that 'listchars' "eol" doesn't affect "gM"
9.1.1248: compile error when building without FEAT_QUICKFIX
9.1.1247: fragile setup to get (preferred) keys from key_name_entry
9.1.1246: coverity complains about some changes in v9.1.1243
9.1.1245: need some more tests for curly braces evaluation
9.1.1244: part of patch v9.1.1242 was wrong
9.1.1243: diff mode is lacking for changes within lines
9.1.1242: Crash when evaluating variable name
9.1.1241: wrong preprocessort indentation in term.c
9.1.1240: Regression with ic/ac text objects and comment plugin
9.1.1239: if_python: no tuple data type support
9.1.1238: wrong cursor column with 'set splitkeep=screen'
9.1.1237: Compile error with C89 compiler in term.c
9.1.1236: tests: test_comments leaves swapfiles around
9.1.1235: cproto files are outdated
9.1.1234: Compile error when SIZE_MAX is not defined
9.1.1233: Coverity warns about NULL pointer when triggering WinResized
9.1.1232: Vim script is missing the tuple data type
9.1.1231: filetype: SPA JSON files are not recognized
9.1.1230: inconsistent CTRL-C behaviour for popup windows
9.1.1229: the comment plugin can be improved
9.1.1228: completion: current position column wrong after got a match
9.1.1227: no tests for the comment package
9.1.1226: "shellcmdline" completion doesn't work with input()
9.1.1225: extra NULL check in VIM_CLEAR()
9.1.1224: cannot :put while keeping indent
9.1.1223: wrong translation used for encoding failures
9.1.1222: using wrong length for last inserted string
9.1.1221: Wrong cursor pos when leaving Insert mode just after 'autoindent'
9.1.1220: filetype: uv.lock file not recognized
9.1.1219: Strange error with wrong type for matchfuzzy() "camelcase"
9.1.1218: missing out-of-memory check in filepath.c
9.1.1217: tests: typos in test_matchfuzzy.vim
9.1.1216: Pasting the '.' register multiple times may not work
9.1.1215: Patch 9.1.1213 has some issues
9.1.1214: matchfuzzy() can be improved for camel case matches
9.1.1213: cannot :put while keeping indent
9.1.1212: too many strlen() calls in edit.c
9.1.1212: filetype: logrotate'd pacmanlogs are not recognized
9.1.1211: TabClosedPre is triggered just before the tab is being freed
9.1.1210: translation(ru): missing Russian translation for the new tutor
9.1.1209: colorcolumn not drawn after virtual text lines
9.1.1208: MS-Windows: not correctly restoring alternate screen on Win 10
9.1.1207: MS-Windows: build warning in filepath.c
9.1.1206: tests: test_filetype fails when a file is a directory
9.1.1205: completion: preinserted text not removed when closing pum
9.1.1204: MS-Windows: crash when passing long string to expand()
9.1.1203: matchparen keeps cursor on case label in sh filetype
9.1.1202: Missing TabClosedPre autocommand
9.1.1201: 'completefuzzycollect' does not handle dictionary correctly
9.1.1200: cmdline pum not cleared for input() completion
9.1.1199: gvim uses hardcoded xpm icon file
9.1.1198: [security]: potential data loss with zip.vim
9.1.1197: process_next_cpt_value() uses wrong condition
9.1.1196: filetype: config files for container tools are not recognized
9.1.1195: inside try-block: fn body executed with default arg undefined
9.1.1194: filetype: false positive help filetype detection
9.1.1193: Unnecessary use of STRCAT() in au_event_disable()
9.1.1192: Vim crashes with term response debug logging enabled
9.1.1191: tests: test for patch 9.1.1186 doesn't fail without the patch
9.1.1190: C indentation does not detect multibyte labels
9.1.1189: if_python: build error due to incompatible pointer types
9.1.1188: runtime(tera): tera support can be improved
9.1.1187: matchparen plugin wrong highlights shell case statement
9.1.1186: filetype: help files in git repos are not detected
9.1.1185: endless loop with completefuzzycollect and no match found
9.1.1184: Unnecessary use of vim_tolower() in vim_strnicmp_asc()
9.1.1083: "above" virtual text breaks cursorlineopt=number
9.1.1182: No cmdline completion for 'completefuzzycollect'
9.1.1181: Unnecessary STRLEN() calls in insexpand.c
9.1.1180: short-description
9.1.1179: too many strlen() calls in misc2.c
9.1.1178: not possible to generate completion candidates using fuzzy matching
9.1.1177: filetype: tera files not detected
- Introduce patch to fix bsc#1235751 (regression).
* vim-9.1.1134-revert-putty-terminal-colors.patch
- Update to 9.1.1176. Changes:
* 9.1.1176: wrong indent when expanding multiple lines
* 9.1.1175: inconsistent behaviour with exclusive selection and motion commands
* 9.1.1174: tests: Test_complete_cmdline() may fail
* 9.1.1173: filetype: ABNF files are not detected
* 9.1.1172: [security]: overflow with 'nostartofline' and Ex command in tag file
* 9.1.1171: tests: wrong arguments passed to assert_equal()
* 9.1.1170: wildmenu highlighting in popup can be improved
* 9.1.1169: using global variable for get_insert()/get_lambda_name()
* 9.1.1168: wrong flags passed down to nextwild()
* 9.1.1167: mark '] wrong after copying text object
* 9.1.1166: command-line auto-completion hard with wildmenu
* 9.1.1165: diff: regression with multi-file diff blocks
* 9.1.1164: [security]: code execution with tar.vim and special crafted tar files
* 9.1.1163: $MYVIMDIR is set too late
* 9.1.1162: completion popup not cleared in cmdline
* 9.1.1161: preinsert requires bot "menu" and "menuone" to be set
* 9.1.1160: Ctrl-Y does not work well with "preinsert" when completing items
* 9.1.1159: $MYVIMDIR may not always be set
* 9.1.1158: :verbose set has wrong file name with :compiler!
* 9.1.1157: command completion wrong for input()
* 9.1.1156: tests: No test for what patch 9.1.1152 fixes
* 9.1.1155: Mode message not cleared after :silent message
* 9.1.1154: Vim9: not able to use autoload class accross scripts
* 9.1.1153: build error on Haiku
* 9.1.1152: Patch v9.1.1151 causes problems
* 9.1.1151: too many strlen() calls in getchar.c
* 9.1.1150: :hi completion may complete to wrong value
* 9.1.1149: Unix Makefile does not support Brazilian lang for the installer
* 9.1.1148: Vim9: finding imported scripts can be further improved
* 9.1.1147: preview-window does not scroll correctly
* 9.1.1146: Vim9: wrong context being used when evaluating class member
* 9.1.1145: multi-line completion has wrong indentation for last line
* 9.1.1144: no way to create raw strings from a blob
* 9.1.1143: illegal memory access when putting a register
* 9.1.1142: tests: test_startup fails if $HOME/$XDG_CONFIG_HOME is defined
* 9.1.1141: Misplaced comment in readfile()
* 9.1.1140: filetype: m17ndb files are not detected
* 9.1.1139: [fifo] is not displayed when editing a fifo
* 9.1.1138: cmdline completion for :hi is too simplistic
* 9.1.1137: ins_str() is inefficient by calling STRLEN()
* 9.1.1136: Match highlighting marks a buffer region as changed
* 9.1.1135: 'suffixesadd' doesn't work with multiple items
* 9.1.1134: filetype: Guile init file not recognized
* 9.1.1133: filetype: xkb files not recognized everywhere
* 9.1.1132: Mark positions wrong after triggering multiline completion
* 9.1.1131: potential out-of-memory issue in search.c
* 9.1.1130: 'listchars' "precedes" is not drawn on Tabs.
* 9.1.1129: missing out-of-memory test in buf_write()
* 9.1.1128: patch 9.1.1119 caused a regression with imports
* 9.1.1127: preinsert text is not cleaned up correctly
* 9.1.1126: patch 9.1.1121 used a wrong way to handle enter
* 9.1.1125: cannot loop through pum menu with multiline items
* 9.1.1124: No test for 'listchars' "precedes" with double-width char
* 9.1.1123: popup hi groups not falling back to defaults
* 9.1.1122: too many strlen() calls in findfile.c
* 9.1.1121: Enter does not insert newline with "noselect"
* 9.1.1120: tests: Test_registers fails
* 9.1.1119: Vim9: Not able to use an autoloaded class from another autoloaded script
* 9.1.1118: tests: test_termcodes fails
* 9.1.1117: there are a few minor style issues
* 9.1.1116: Vim9: super not supported in lambda expressions
* 9.1.1115: [security]: use-after-free in str_to_reg()
* 9.1.1114: enabling termguicolors automatically confuses users
* 9.1.1113: tests: Test_terminal_builtin_without_gui waits 2 seconds
* 9.1.1112: Inconsistencies in get_next_or_prev_match()
* 9.1.1111: Vim9: variable not found in transitive import
* 9.1.1110: Vim tests are slow and flaky
* 9.1.1109: cmdexpand.c hard to read
* 9.1.1108: 'smoothscroll' gets stuck with 'listchars' "eol"
* 9.1.1107: cannot loop through completion menu with fuzzy
* 9.1.1106: tests: Test_log_nonexistent() causes asan failure
* 9.1.1105: Vim9: no support for protected new() method
* 9.1.1104: CI: using Ubuntu 22.04 Github runners
* 9.1.1103: if_perl: still some compile errors with Perl 5.38
* 9.1.1102: tests: Test_WinScrolled_Resized_eiw() uses wrong filename
- 9.1.1101 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 & 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 "trim"
* tests: test_compiler fails on Windows without Maven
* 'diffopt' "linematch" 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 <C-W>/<C-U>
* 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 "Approaches the limit"
* 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
* "nosort" enables fuzzy filtering even if "fuzzy" 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 "git vimdumps"
* 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-<name> 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 "Zero" 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 "gq" 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 "noselect" 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
- Fix for bsc#1231373 / CVE-2024-47814.
- Fix for bsc#1229238 / CVE-2024-43374.
- update to 9.1.0836
* 9.1.0836: The vimtutor can be improved
* 9.1.0835: :setglobal doesn't work properly for 'ffu' and 'tsrfu'
* 9.1.0834: tests: 2html test fails
* 9.1.0833: CI: recent ASAN changes do not work for indent tests
* 9.1.0832: :set doesn't work for 'cot' and 'bkc' after :setlocal
* runtime(doc): update help-toc description
* runtime(2html): Make links use color scheme colors in TOhtml
* 9.1.0831: 'findexpr' can't be used as lambad or Funcref
* Filelist: include helptoc package
* runtime(doc): include a TOC Vim9 plugin
* Filelist: ignore .git-blame-ignore-revs
* 9.1.0830: using wrong highlight group for spaces for popupmenu
* runtime(typst): synchronize updates from the upstream typst.vim
* git: ignore reformatting commit for git-blame (after v9.1.0829)
* 9.1.0829: Vim source code uses a mix of tabs and spaces
* 9.1.0828: string_T struct could be used more often
* 9.1.0827: CI: tests can be improved
* runtime(doc): remove stray sentence in pi_netrw.txt
* 9.1.0826: filetype: sway files are not recognized
* runtime(doc): Include netrw-gp in TOC
* runtime(doc): mention 'iskeyword' at :h charclass()
* runtime(doc): update help tags
* 9.1.0825: compile error for non-diff builds
* runtime(netrw): fix E874 when browsing remote directory which contains `~` character
* runtime(doc): update coding style documentation
* runtime(debversions): Add plucky (25.04) as Ubuntu release name
* 9.1.0824: too many strlen() calls in register.c
* 9.1.0823: filetype: Zephyr overlay files not recognized
* runtime(doc): Clean up minor formatting issues for builtin functions
* runtime(netrw): make :Launch/Open autoloadable
* runtime(netrw): fix regression with x mapping on Cygwin
* runtime(netrw): fix filetype detection for remote files
* 9.1.0822: topline might be changed in diff mode unexpectedly
* CI: huge linux builds should also run syntax & indent tests
* 9.1.0821: 'findexpr' completion doesn't set v:fname to cmdline argument
* 9.1.0820: tests: Mac OS tests are too flaky
* runtime(awk): Highlight more awk comments in syntax script
* runtime(netrw): add missing change for s:redir()
* 9.1.0819: tests: using findexpr and imported func not tested
* runtime(netrw): improve netrw's open-handling further
* runtime(netrw): fix syntax error in netrwPlugin.vim
* runtime(netrw): simplify gx file handling
* 9.1.0818: some global functions are only used in single files
* 9.1.0817: termdebug: cannot evaluate expr in a popup
* runtime(defaults): Detect putty terminal and switch to dark background
* 9.1.0816: tests: not clear what tests cause asan failures
* runtime(doc): Remove some completed items from todo.txt
* 9.1.0815: "above" virtual text causes wrong 'colorcolumn' position
* runtime(syntax-tests): tiny vim fails because of line-continuation
* 9.1.0814: mapset() may remove unrelated mapping
* 9.1.0813: no error handling with setglobal and number types
* 9.1.0812: Coverity warns about dereferencing NULL ptr
* 9.1.0811: :find expansion does not consider 'findexpr'
* 9.1.0810: cannot easily adjust the |:find| command
* 9.1.0809: filetype: petalinux config files not recognized
* 9.1.0808: Terminal scrollback doesn't shrink when decreasing 'termwinscroll'
* 9.1.0807: tests: having 'nolist' in modelines isn't always desired
* 9.1.0806: tests: no error check when setting global 'briopt'
* 9.1.0805: tests: minor issues in gen_opt_test.vim
* 9.1.0804: tests: no error check when setting global 'cc'
* 9.1.0803: tests: no error check when setting global 'isk'
* 9.1.0802: tests: no error check when setting global 'fdm' to empty value
* 9.1.0801: tests: no error check when setting global 'termwinkey'
* 9.1.0800: tests: no error check when setting global 'termwinsize'
* runtime(doc): :ownsyntax also resets 'spelloptions'
* 9.1.0799: tests: gettwinvar()/gettabwinvar() tests are not comprehensive
* runtime(doc): Fix wrong Mac default options
* 9.1.0798: too many strlen() calls in cmdhist.c
* 9.1.0797: testing of options can be further improved
* 9.1.0796: filetype: libtool files are not recognized
* (typst): add folding to typst ftplugin
* runtime(netrw): deprecate and remove netrwFileHandlers#Invoke()
* 9.1.0795: filetype: Vivado memory info file are not recognized
* 9.1.0794: tests: tests may fail on Windows environment
* runtime(doc): improve the :colorscheme documentation
* 9.1.0793: xxd: -e does add one extra space
* 9.1.0792: tests: Test_set_values() is not comprehensive enough
* runtime(swayconfig): add flag for bindsym/bindcode to syntax script
* 9.1.0791: tests: errors in gen_opt_test.vim are not shown
* runtime(compiler): check for compile_commands in build dirs for cppcheck
* 9.1.0790: Amiga: AmigaOS4 build should use default runtime (newlib)
* runtime(help): Update help syntax
* runtime(help): fix end of sentence highlight in code examples
* runtime(jinja): Support jinja syntax as secondary filetype
* 9.1.0789: tests: ':resize + 5' has invalid space after '+'
* 9.1.0788: <CSI>27;<mod>u is not decoded to literal Escape in kitty/foot
* 9.1.0787: cursor position changed when using hidden terminal
* 9.1.0786: tests: quickfix update test does not test location list
* runtime(doc): add some docs for file-watcher programs
* CI: uploading failed screendumps still fails on Cirrus CI
* 9.1.0785: cannot preserve error position when setting quickfix list
* 9.1.0784: there are several problems with python 3.13
* 9.1.0783: 'spell' option setting has problems
* 9.1.0782: tests: using wrong neomuttlog file name
* runtime(doc): add preview flag to statusline example
* 9.1.0781: tests: test_filetype fails
* 9.1.0780: MS-Windows: incorrect Win32 error checking
* 9.1.0779: filetype: neomuttlog files are not recognized
* 9.1.0778: filetype: lf config files are not recognized
* runtime(comment): fix commment toggle with mixed tabs & spaces
* runtime(misc): Use consistent "Vim script" spelling
* runtime(gleam): add ftplugin for gleam files
* runtime(doc): link help-writing from write-local-help
* 9.1.0777: filetype: Some upstream php files are not recognized
* runtime(java): Define javaBlockStart and javaBlockOtherStart hl groups
* runtime(doc): mention conversion rules for remote_expr()
* runtime(tutor): Fix missing :s command in spanish translation section 4.4
* 9.1.0776: test_strftime may fail because of missing TZ data
* translation(am): Add Armenian language translation
* 9.1.0775: tests: not enough tests for setting options
* 9.1.0774: "shellcmdline" doesn't work with getcompletion()
* 9.1.0773: filetype: some Apache files are not recognized
* 9.1.0772: some missing changes from v9.1.0771
* 9.1.0771: completion attribute hl_group is confusing
* 9.1.0770: current command line completion is a bit limited
* 9.1.0769: filetype: MLIR files are not recognized
* 9.1.0768: MS-Windows: incorrect cursor position when restoring screen
* runtime(nasm): Update nasm syntax script
* 9.1.0767: A condition is always true in ex_getln.c
* runtime(skill): Update syntax file to fix string escapes
* runtime(help): highlight CTRL-<Key> correctly
* runtime(doc): add missing usr_52 entry to toc
* 9.1.0766: too many strlen() calls in ex_getln.c
* runtime(doc): correct `vi` registers 1-9 documentation error
* 9.1.0765: No test for patches 6.2.418 and 7.3.489
* runtime(spec): set comments and commentstring options
* NSIS: Include libgcc_s_sjlj-1.dll again
* runtime(doc): clarify the effect of 'startofline' option
* 9.1.0764: [security]: use-after-free when closing a buffer
* runtime(vim): Update base-syntax file, improve class, enum and interface highlighting
* 9.1.0763: tests: cannot run single syntax tests
* 9.1.0762: 'cedit', 'termwinkey' and 'wildchar' may not be parsed correctly
* 9.1.0761: :cd completion fails on Windows with backslash in path
* 9.1.0760: tests: no error reported, if gen_opt_test.vim fails
* 9.1.0759: screenpos() may return invalid position
* runtime(misc): unset compiler in various ftplugins
* runtime(doc): update formatting and syntax
* runtime(compiler): add cppcheck linter compiler plugin
* runtime(doc): Fix style in documents
* runtime(doc): Fix to two-space convention in user manual
* runtime(comment): consider &tabstop in lines after whitespace indent
* 9.1.0758: it's possible to set an invalid key to 'wildcharm'
* runtime(java): Manage circularity for every :syn-included syntax file
* 9.1.0757: tests: messages files contains ANSI escape sequences
* 9.1.0756: missing change from patch v9.1.0754
* 9.1.0755: quickfix list does not handle hardlinks well
* runtime(doc): 'filetype', 'syntax' and 'keymap' only allow alphanumeric + some characters
* runtime(systemd): small fixes to &keywordprg in ftplugin
* CI: macos-12 runner is being sunset, switch to 13
* 9.1.0754: fixed order of items in insert-mode completion menu
* runtime(comment): commenting might be off by one column
* 9.1.0753: Wrong display when typing in diff mode with 'smoothscroll'
* 9.1.0752: can set 'cedit' to an invalid value
* runtime(doc): add `usr` tag to usr_toc.txt
* 9.1.0751: Error callback for term_start() not used
* 9.1.0750: there are some Win9x legacy references
* runtime(java): Recognise the CommonMark form (///) of Javadoc comments
* 9.1.0749: filetype: http files not recognized
* runtime(comment): fix syntax error
* CI: uploading failed screendump tests does not work Cirrus
* 9.1.0748: :keep* commmands are sometimes misidentified as :k
* runtime(indent): allow matching negative numbers for gnu indent config file
* runtime(comment): add gC mapping to (un)comment rest of line
* 9.1.0747: various typos in repo found
* 9.1.0746: tests: Test_halfpage_longline() fails on large terminals
* runtime(doc): reformat gnat example
* runtime(doc): reformat ada_standard_types section
* 9.1.0745: filetype: bun and deno history files not recognized
* runtime(glvs): Correct the tag name of glvs-autoinstal
* runtime(doc): include short form for :earlier/:later
* runtime(doc): remove completed TODO
* 9.1.0744: filetype: notmuch configs are not recognised
* 9.1.0743: diff mode does not handle overlapping diffs correctly
* runtime(glvs): fix a few issues
* runtime(doc): Fix typo in :help :command-modifiers
* 9.1.0742: getcmdprompt() implementation can be improved
* runtime(docs): update `:set?` command behavior table
* runtime(doc): update vim90 to vim91 in docs
* runtime(doc): fix typo in :h dos-colors
* 9.1.0741: No way to get prompt for input()/confirm()
* runtime(doc): fix typo in version9.txt nrformat -> nrformats
* runtime(rmd,rrst): 'fex' option not properly restored
* runtime(netrw): remove extraneous closing bracket
* 9.1.0740: incorrect internal diff with empty file
* 9.1.0739: [security]: use-after-free in ex_getln.c
* runtime(filetype): tests: Test_filetype_detection() fails
* runtime(dist): do not output a message if executable is not found
* 9.1.0738: filetype: rapid files are not recognized
* runtime(modconf): remove erroneous :endif in ftplugin
* runtime(lyrics): support multiple timestamps in syntax script
* runtime(java): Optionally recognise _module_ import declarations
* runtime(vim): Update base-syntax, improve folding function matches
* CI: upload failed screendump tests also for Cirrus
* 9.1.0737: tests: screendump tests may require a bit more time
* runtime(misc): simplify keywordprg in various ftplugins
* runtime(java): Optionally recognise all primitive constants in _switch-case_ labels
* runtime(zsh,sh): set and unset compiler in ftplugin
* runtime(netrw): using inefficient highlight pattern for 'mf'
* 9.1.0736: Unicode tables are outdated
* 9.1.0735: filetype: salt files are not recognized
* 9.1.0734: filetype: jinja files are not recognized
* runtime(zathurarc): add double-click-follow to syntax script
* translation(ru): Updated messages translation
* translation(it): updated xxd man page
* translation(ru): updated xxd man page
* 9.1.0733: keyword completion does not work with fuzzy
* 9.1.0732: xxd: cannot use -b and -i together
* runtime(java): Highlight javaConceptKind modifiers with StorageClass
* runtime(doc): reword and reformat how to use defaults.vim
* 9.1.0731: inconsistent case sensitive extension matching
* runtime(vim): Update base-syntax, match Vim9 bool/null literal args to :if/:while/:return
* runtime(netrw): delete confirmation not strict enough
* 9.1.0730: Crash with cursor-screenline and narrow window
* 9.1.0729: Wrong cursor-screenline when resizing window
* 9.1.0728: [security]: heap-use-after-free in garbage collection with location list user data
* runtime(doc): clarify the effect of the timeout for search()-functions
* runtime(idlang): update syntax script
* runtime(spec): Recognize epoch when making spec changelog in ftplugin
* runtime(spec): add file triggers to syntax script
* 9.1.0727: too many strlen() calls in option.c
* runtime(make): add compiler/make.vim to reset compiler plugin settings
* runtime(java): Recognise all available standard doclet tags
* 9.1.0726: not using correct python3 API with dynamic linking
* runtime(dosini): Update syntax script, spellcheck comments only
* runtime(doc): Revert outdated comment in completeopt's fuzzy documentation
* 9.1.0725: filetype: swiftinterface files are not recognized
* runtime(pandoc): Update compiler plugin to use actual 'spelllang'
* runtime(groff): Add compiler plugin for groff
* 9.1.0724: if_python: link error with python 3.13 and stable ABI
* 9.1.0723: if_python: dynamic linking fails with python3 >= 3.13
* 9.1.0722: crash with large id in text_prop interface
* 9.1.0721: tests: test_mksession does not consider XDG_CONFIG_HOME
* runtime(glvs): update GetLatestVimScripts plugin
* runtime(doc): Fix typo in :help :hide text
* runtime(doc): buffers can be re-used
* 9.1.0720: Wrong breakindentopt=list:-1 with multibyte or TABs
* 9.1.0719: Resetting cell widths can make 'listchars' or 'fillchars' invalid
* runtime(doc): Update version9.txt and mention $MYVIMDIR
- Update to 9.1.0718:
* v9.1.0718: hard to know the users personal Vim Runtime Directory
* v9.1.0717: Unnecessary nextcmd NULL checks in parse_command_modifiers()
Maintainers: fix typo in author name
* v9.1.0716: resetting setcellwidth( doesn't update the screen
runtime(hcl,terraform): Add runtime files for HCL and Terraform
runtime(tmux): Update syntax script
* v9.1.0715: Not correctly parsing color names (after v9.1.0709)
* v9.1.0714: GuiEnter_Turkish test may fail
* v9.1.0713: Newline causes E749 in Ex mode
* v9.1.0712: missing dependency of Test_gettext_makefile
* v9.1.0711: test_xxd may file when using different xxd
* v9.1.0710: popup window may hide part of Command line
runtime(vim): Update syntax, improve user-command matching
* v9.1.0709: GUIEnter event not found in Turkish locale
runtime(sudoers): improve recognized Runas_Spec and Tag_Spec items
* v9.1.0708: Recursive window update does not account for reset skipcol
runtime(nu): include filetype plugin
* v9.1.0707: invalid cursor position may cause a crash
* v9.1.0706: test_gettext fails when using shadow dir
CI: Install locales-all package
* v9.1.0705: Sorting of fuzzy filename completion is not stable
translation(pt): update Portuguese/Brazilian menu translation
runtime(vim): Update base-syntax, match bracket mark ranges
runtime(doc): Update :help :command-complete list
* v9.1.0704: inserting with a count is inefficient
runtime(doc): use mkdir -p to save a command
* v9.1.0703: crash with 2byte encoding and glob2regpat()
runtime(hollywood): update syn highlight for If-Then statements
and For-In-Loops
* v9.1.0702: Patch 9.1.0700 broke CI
* v9.1.0701: crash with NFA regex engine when searching for
composing chars
* v9.1.0700: crash with 2byte encoding and glob2regpat()
* v9.1.0699: "dvgo" is not always an inclusive motion
runtime(java): Provide support for syntax preview features
* v9.1.0698: "Untitled" file not removed when running Test_crash1_3
alone
* v9.1.0697: heap-buffer-overflow in ins_typebuf
* v9.1.0696: installing runtime files fails when using SHADOWDIR
runtime(doc): fix typo
* v9.1.0695: test_crash leaves Untitled file around
translation(br): Update Brazilian translation
translation(pt): Update menu_pt_br
* v9.1.0694: matchparen is slow on a long line
* v9.1.0693: Configure doesn't show result when not using python3
stable abi
* v9.1.0692: Wrong patlen value in ex_substitute()
* v9.1.0691: stable-abi may cause segfault on Python 3.11
runtime(vim): Update base-syntax, match :loadkeymap after colon and bar
runtime(mane): Improve <Plug>ManBS mapping
* v9.1.0690: cannot set special highlight kind in popupmenu
translation(pt): Revert and fix wrong Portuguese menu translation
files
translation(pt): revert Portuguese menu translation
translation(br): Update Brazilian translations
runtime(vim): Update base-syntax, improve :let-heredoc highlighting
* v9.1.0689: buffer-overflow in do_search( with 'rightleft'
runtime(vim): Improve heredoc handling for all embedded scripts
* v9.1.0688: dereferences NULL pointer in check_type_is_value()
* v9.1.0687: Makefile may not install desktop files
runtime(man): Fix <Plug>ManBS
runtime(java): Make the bundled &foldtext function optional
runtime(netrw): Change line on `mx` if command output exists
runtime(netrw): Fix `mf`-selected entry highlighting
runtime(htmlangular): add html syntax highlighting
translation(it): Fix filemode of Italian manpages
runtime(doc): Update outdated man.vim plugin information
runtime(zip): simplify condition to detect MS-Windows
* v9.1.0686: zip-plugin has problems with special characters
runtime(pandoc): escape quotes in &errorformat for pandoc
translation(it): updated Italian manpage
* v9.1.0685: too many strlen( calls in usercmd.c
runtime(doc): fix grammar in :h :keeppatterns
runtime(pandoc): refine pandoc compiler settings
* v9.1.0684: completion is inserted on Enter with "noselect"
translation(ru): update man pages
* v9.1.0683: mode( returns wrong value with <Cmd> mapping
runtime(doc): remove trailing whitespace in cmdline.txt
* v9.1.0682: Segfault with uninitialized funcref
* v9.1.0681: Analyzing failed screendumps is hard
runtime(doc): more clarification for the :keeppatterns needed
* v9.1.0680: VMS does not have defined uintptr_t
runtime(doc): improve typedchar documentation for KeyInputPre autocmd
runtime(dist): verify that executable is in $PATH
translation(it): update Italian manpages
runtime(doc): clarify the effect of :keeppatterns after * v9.1.0677
runtime(doc): update Makefile and make it portable between GNU and BSD
* v9.1.0679: Rename from w_closing to w_locked is incomplete
runtime(colors): update colorschemes
runtime(vim): Update base-syntax, improve :let-heredoc highlighting
runtime(doc): Updating the examples in the xxd manpage
translation(ru): Updated uganda.rux
runtime(yaml): do not re-indent when commenting out lines
* v9.1.0678: use-after-free in alist_add()
* v9.1.0677 :keepp does not retain the substitute pattern
translation(ja): Update Japanese translations to latest release
runtime(netrw): Drop committed trace lines
runtime(netrw): Error popup not always used
runtime(netrw): ErrorMsg( may throw E121
runtime(tutor): update Makefile and make it portable between GNU and BSD
translation: improve the po/cleanup.vim script
runtime(lang): update Makefile and make it portable between GNU and BSD
* v9.1.0676: style issues with man pages
* v9.1.0675: Patch v9.1.0674 causes problems
runtime(dosbatch): Show %%i as an argument in syntax file
runtime(dosbatch): Add syn-sync to syntax file
runtime(sql, mysql): fix E169: Command too recursive with
sql_type_default = "mysql"
* v9.1.0674: compiling abstract method fails because of missing return
runtime(javascript): fix a few issues with syntax higlighting
runtime(mediawiki): fix typo in doc, test for b:did_ftplugin var
runtime(termdebug): Fix wrong test for balloon feature
runtime(doc): Remove mentioning of the voting feature
runtime(doc): add help tags for json + markdown global variables
* v9.1.0673: too recursive func calls when calling super-class method
runtime(syntax-tests): Facilitate the viewing of rendered screendumps
runtime(doc): fix a few style issues
* v9.1.0672: marker folds may get corrupted on undo
* v9.1.0671 Problem: crash with WinNewPre autocommand
* v9.1.0670: po file encoding fails on *BSD during make
translation(it): Update Italian translation
translation: Stop using msgconv
* v9.1.0669: stable python ABI not used by default
Update .gitignore and .hgignore files
* v9.1.0668: build-error with python3.12 and stable ABI
translations: Update generated po files
* v9.1.0667: Some other options reset curswant unnecessarily when set
* v9.1.0666: assert_equal( doesn't show multibyte string correctly
runtime(doc): clarify directory of Vim's executable vs CWD
* v9.1.0665 :for loop
runtime(proto): Add indent script for protobuf filetype
* v9.1.0664: console vim did not switch back to main screen on exit
runtime(zip): zip plugin does not work with Vim 9.0
* v9.1.0663: zip test still resets 'shellslash' option
runtime(zip): use defer to restore old settings
runtime(zip): add a generic Message function
runtime(zip): increment base version of zip plugin
runtime(zip): raise minimum Vim version to * v9.0
runtime(zip): refactor save and restore of options
runtime(zip): remove test for fnameescape
runtime(zip): use :echomsg instead of :echo
runtime(zip): clean up and remove comments
* v9.1.0662: filecopy( may return wrong value when readlink( fails
* v9.1.0661: the zip plugin is not tested.
runtime(zip): Fix for FreeBSD's unzip command
runtime(doc): capitalize correctly
* v9.1.0660: Shift-Insert does work on old conhost
translation(it): update Italian manpage
runtime(lua): add/subtract a 'shiftwidth' after '('/')' in indentexpr
runtime(zip): escape '[' on Unix as well
* v9.1.0659: MSVC Makefile is a bit hard to read
runtime(doc): fix typo in syntax.txt
runtime(doc): -x is only available when compiled with crypt feature
* v9.1.0658: Coverity warns about dereferencing NULL pointer.
runtime(colors): update Todo highlight in habamax colorscheme
* v9.1.0657: MSVC build time can be optimized
* v9.1.0656: MSVC Makefile CPU handling can be improved
* v9.1.0655: goaccess config file not recognized
CI: update clang compiler to version 20
runtime(netrw): honor `g:netrw_alt{o,v}` for `:{S,H,V}explore`
* v9.1.0654: completion does not respect completeslash with fuzzy
* v9.1.0653: Patch v9.1.0648 not completely right
* v9.1.0652: too many strlen( calls in syntax.c
* v9.1.0651 :append
* v9.1.0650: Coverity warning in cstrncmp()
* v9.1.0649: Wrong comment for "len" argument of call_simple_func()
* v9.1.0648: [security] double-free in dialog_changed()
* v9.1.0647: [security] use-after-free in tagstack_clear_entry
runtime(doc): re-format tag example lines, mention ctags --list-kinds
* v9.1.0646: imported function may not be found
runtime(java): Document "g:java_space_errors" and "g:java_comment_strings"
runtime(java): Cluster optional group definitions and their group links
runtime(java): Tidy up the syntax file
runtime(java): Tidy up the documentation for "ft-java-syntax"
runtime(colors): update habamax scheme - tweak diff/search/todo colors
runtime(nohlsearch): add missing loaded_hlsearch guard
runtime(kivy): Updated maintainer info for syntax script
Maintainers: Add maintainer for ondir ftplugin + syntax files
runtime(netrw): removing trailing slash when copying files in same
directory
* v9.1.0645: wrong match when searching multi-byte char case-insensitive
runtime(html): update syntax script to sync by 250 minlines by default
* v9.1.0644: Unnecessary STRLEN( when applying mapping
runtime(zip): Opening a remote zipfile don't work
runtime(cuda): source c and cpp ftplugins
* v9.1.0643: cursor may end up on invalid position
* v9.1.0642: Check that mapping rhs starts with lhs fails if not
simplified
* v9.1.0641: OLE enabled in console version
runtime(thrift): add ftplugin, indent and syntax scripts
* v9.1.0640: Makefile can be improved
* v9.1.0639: channel timeout may wrap around
* v9.1.0638: E1510 may happen when formatting a message for smsg()
* v9.1.0637: Style issues in MSVC Makefile
- Update apparmor.vim to latest version (from AppArmor 4.0.2)
- add support for "all" and "userns" rules, and new profile flags
- Update to 9.1.0636:
* 9.1.0636: filetype: ziggy files are not recognized
* 9.1.0635: filetype: SuperHTML template files not recognized
* 9.1.0634: Ctrl-P not working by default
* 9.1.0633: Compilation warnings with `-Wunused-parameter`
* 9.1.0632: MS-Windows: Compiler Warnings
Add support for Files-Included in syntax script
tweak documentation style a bit
* 9.1.0631: wrong completion list displayed with non-existing dir + fuzzy completion
* 9.1.0630: MS-Windows: build fails with VIMDLL and mzscheme
* 9.1.0629: Rename of pum hl_group is incomplete
* 9.1.0628: MinGW: coverage files are not cleaned up
* 9.1.0627: MinGW: build-error when COVERAGE is enabled
* 9.1.0626: Vim9: need more tests with null objects
include initial filetype plugin
* 9.1.0625: tests: test output all translated messages for all translations
* 9.1.0624: ex command modifiers not found
* 9.1.0623: Mingw: errors when trying to delete non-existing files
* 9.1.0622: MS-Windows: mingw-build can be optimized
* 9.1.0621: MS-Windows: startup code can be improved
* 9.1.0620: Vim9: segfauls with null objects
* 9.1.0619: tests: test_popup fails
* 9.1.0618: cannot mark deprecated attributes in completion menu
* 9.1.0617: Cursor moves beyond first line of folded end of buffer
* 9.1.0616: filetype: Make syntax highlighting off for MS Makefiles
* 9.1.0615: Unnecessary STRLEN() in make_percent_swname()
Add single-line comment syntax
Add syntax test for comments
Update maintainer info
* 9.1.0614: tests: screendump tests fail due to recent syntax changes
* 9.1.0613: tests: termdebug test may fail and leave file around
Update base-syntax, improve :set highlighting
Optionally highlight the :: token for method references
* 9.1.0612: filetype: deno.lock file not recognized
Use delete() for deleting directory
escape filename before trying to delete it
* 9.1.0611: ambiguous mappings not correctly resolved with modifyOtherKeys
correctly extract file from zip browser
* 9.1.0610: filetype: OpenGL Shading Language files are not detected
Fix endless recursion in netrw#Explore()
* 9.1.0609: outdated comments in Makefile
update syntax script
Fix flow mapping key detection
Remove orphaned YAML syntax dump files
* 9.1.0608: Coverity warns about a few potential issues
Update syntax script and remove syn sync
* 9.1.0607: termdebug: uses inconsistent style
* 9.1.0606: tests: generated files may cause failure in test_codestyle
* 9.1.0605: internal error with fuzzy completion
* 9.1.0604: popup_filter during Press Enter prompt seems to hang
translation: Update Serbian messages translation
* 9.1.0603: filetype: use correct extension for Dracula
* 9.1.0602: filetype: Prolog detection can be improved
fix more inconsistencies in assert function docs
* 9.1.0601: Wrong cursor position with 'breakindent' when wide char doesn't fit
Update base-syntax, improve :map highlighting
* 9.1.0600: Unused function and unused error constants
* 9.1.0599: Termdebug: still get E1023 when specifying arguments
correct wrong comment options
fix typo "a xterm" -> "an xterm"
* 9.1.0598: fuzzy completion does not work with default completion
* 9.1.0597: KeyInputPre cannot get the (unmapped typed) key
* 9.1.0596: filetype: devscripts config files are not recognized
gdb file/folder check is now performed only in CWD.
quote filename arguments using double quotes
update syntax to SDC-standard 2.1
minor updates.
Cleanup :match and :loadkeymap syntax test files
Update base-syntax, match types in Vim9 variable declarations
* 9.1.0595: make errors out with the po Makefile
* 9.1.0594: Unnecessary redraw when setting 'winfixbuf'
using wrong highlight for UTF-8
include simple syntax plugin
* 9.1.0593: filetype: Asymptote files are not recognized
add recommended indent options to ftplugin
add recommended indent options to ftplugin
add recommended indent options to ftplugin
* 9.1.0592: filetype: Mediawiki files are not recognized
* 9.1.0591: filetype: *.wl files are not recognized
* 9.1.0590: Vim9: crash when accessing getregionpos() return value
'cpoptions': Include "z" in the documented default
* 9.1.0589: vi: d{motion} and cw work differently than expected
update included colorschemes
grammar fixes in options.txt
- Add "Keywords" to gvim.desktop to make searching for gvim easier
- Removed patches, as they're no longer required (refreshing them
deleted their contents):
* vim-7.3-help_tags.patch
* vim-7.4-highlight_fstab.patch
- Reorganise all applied patches in the spec file.
- Update to 9.1.0588:
* 9.1.0588: The maze program no longer compiles on newer clang
runtime(typst): Add typst runtime files
* 9.1.0587: tests: Test_gui_lowlevel_keyevent is still flaky
* 9.1.0586: ocaml runtime files are outdated
runtime(termdebug): fix a few issues
* 9.1.0585: tests: test_cpoptions leaves swapfiles around
* 9.1.0584: Warning about redeclaring f_id() non-static
runtime(doc): Add hint how to load termdebug from vimrc
runtime(doc): document global insert behavior
* 9.1.0583: filetype: *.pdf_tex files are not recognized
* 9.1.0582: Printed line doesn't overwrite colon when pressing Enter in Ex mode
* 9.1.0581: Various lines are indented inconsistently
* 9.1.0580: :lmap mapping for keypad key not applied when typed in Select mode
* 9.1.0579: Ex command is still executed after giving E1247
* 9.1.0578: no tests for :Tohtml
* 9.1.0577: Unnecessary checks for v:sizeoflong in test_put.vim
* 9.1.0576: tests: still an issue with test_gettext_make
* 9.1.0575: Wrong comments in alt_tabpage()
* 9.1.0574: ex: wrong handling of commands after bar
runtime(doc): add a note for netrw bug reports
* 9.1.0573: ex: no implicit print for single addresses
runtime(vim): make &indentexpr available from the outside
* 9.1.0572: cannot specify tab page closing behaviour
runtime(doc): remove obsolete Ex insert behavior
* 9.1.0571: tests: Test_gui_lowlevel_keyevent is flaky
runtime(logindefs): update syntax with new keywords
* 9.1.0570: tests: test_gettext_make can be improved
runtime(filetype): Fix Prolog file detection regex
* 9.1.0569: fnamemodify() treats ".." and "../" differently
runtime(mojo): include mojo ftplugin and indent script
* 9.1.0568: Cannot expand paths from 'cdpath' setting
* 9.1.0567: Cannot use relative paths as findfile() stop directories
* 9.1.0566: Stop dir in findfile() doesn't work properly w/o trailing slash
* 9.1.0565: Stop directory doesn't work properly in 'tags'
* 9.1.0564: id() can be faster
* 9.1.0563: Cannot process any Key event
* 9.1.0562: tests: inconsistency in test_findfile.vim
runtime(fstab): Add missing keywords to fstab syntax
* 9.1.0561: netbeans: variable used un-initialized (Coverity)
* 9.1.0560: bindtextdomain() does not indicate an error
* 9.1.0559: translation of vim scripts can be improved
* 9.1.0558: filetype: prolog detection can be improved
* 9.1.0557: moving in the buffer list doesn't work as documented
runtime(doc): fix inconsistencies in :h file-searching
* 9.1.0556: :bwipe doesn't remove file from jumplist of other tabpages
runtime(htmlangular): correct comment
* 9.1.0555: filetype: angular ft detection is still problematic
* 9.1.0554: :bw leaves jumplist and tagstack data around
* 9.1.0553: filetype: *.mcmeta files are not recognized
* 9.1.0552: No test for antlr4 filetype
* 9.1.0551: filetype: htmlangular files are not properly detected
* 9.1.0550: filetype: antlr4 files are not recognized
* 9.1.0549: fuzzycollect regex based completion not working as expected
runtime(doc): autocmd_add() accepts a list not a dict
* 9.1.0548: it's not possible to get a unique id for some vars
runtime(tmux): Update syntax script
* 9.1.0547: No way to get the arity of a Vim function
* 9.1.0546: vim-tiny fails on CTRL-X/CTRL-A
runtime(hlsplaylist): include hlsplaylist ftplugin file
runtime(doc): fix typo in :h ft-csv-syntax
runtime(doc): Correct shell command to get $VIMRUNTIME into
shell
* 9.1.0545: MSVC conversion warning
* 9.1.0544: filetype: ldapconf files are not recognized
runtime(cmakecache): include cmakecache ftplugin file
runtime(lex): include lex ftplugin file
runtime(yacc): include yacc ftplugin file
runtime(squirrel): include squirrel ftplugin file
runtime(objcpp): include objcpp ftplugin file
runtime(tf): include tf ftplugin file
runtime(mysql): include mysql ftplugin file
runtime(javacc): include javacc ftplugin file
runtime(cabal): include cabal ftplugin file
runtime(cuda): include CUDA ftplugin file
runtime(editorconfig): include editorconfig ftplugin file
runtime(kivy): update kivy syntax, include ftplugin
runtime(syntax-tests): Stop generating redundant "*_* 99.dump"
files
* 9.1.0543: Behavior of CursorMovedC is strange
runtime(vim): Update base-syntax, improve :match command
highlighting
* 9.1.0542: Vim9: confusing string() output for object functions
* 9.1.0541: failing test with Vim configured without channel
* 9.1.0540: Unused assignment in sign_define_cmd()
runtime(doc): add page-scrolling keys to index.txt
runtime(doc): add reference to xterm-focus-event from
FocusGained/Lost
* 9.1.0539: Not enough tests for what v9.1.0535 fixed
runtime(doc): clarify how to re-init csv syntax file
* 9.1.0538: not possible to assign priority when defining a sign
* 9.1.0537: signed number detection for CTRL-X/A can be improved
* 9.1.0536: filetype: zone files are not recognized
* 9.1.0535: newline escape wrong in ex mode
runtime(man): honor cmd modifiers before `g:ft_man_open_mode`
runtime(man): use `nnoremap` to map to Ex commands
* 9.1.0534: completion wrong with fuzzy when cycling back to original
runtime(syntax-tests): Abort and report failed cursor progress
runtime(syntax-tests): Introduce self tests for screen dumping
runtime(syntax-tests): Clear and redraw the ruler line with
the shell info
runtime(syntax-tests): Allow for folded and wrapped lines in
syntax test files
* 9.1.0533: Vim9: need more tests for nested objects equality
CI: Pre-v* 9.0.0110 versions generate bogus documentation tag entries
runtime(doc): Remove wrong help tag CTRL-SHIFT-CR
* 9.1.0532: filetype: Cedar files not recognized
runtime(doc): document further keys that scroll page up/down
* 9.1.0531: resource leak in mch_get_random()
runtime(tutor): Fix wrong spanish translation
runtime(netrw): fix remaining case of register clobber
* 9.1.0530: xxd: MSVC warning about non-ASCII character
* 9.1.0529: silent! causes following try/catch to not work
runtime(rust): use shiftwidth() in indent script
* 9.1.0528: spell completion message still wrong in translations
* 9.1.0527: inconsistent parameter in Makefiles for Vim executable
* 9.1.0526: Unwanted cursor movement with pagescroll at start of buffer
runtime(doc): mention $XDG_CONFIG_HOME instead of $HOME/.config
* 9.1.0525: Right release selects immediately when pum is truncated.
* 9.1.0524: the recursive parameter in the *_equal functions can be removed
runtime(termdebug): Add Deprecation warnings
* 9.1.0523: Vim9: cannot downcast an object
* 9.1.0522: Vim9: string(object) hangs for recursive references
* 9.1.0521: if_py: _PyObject_CallFunction_SizeT is dropped in Python 3.13
* 9.1.0520: Vim9: incorrect type checking for modifying lists
runtime(manpager): avoid readonly prompt
* 9.1.0519: MS-Windows: libvterm compilation can be optimized
* 9.1.0518: initialize the random buffer can be improved
* 9.1.0517: MS-Windows: too long lines in Make_mvc.mak
runtime(terraform): Add filetype plugin for terraform
runtime(dockerfile): enable spellchecking of comments in
syntax script
runtime(doc): rename variable for pandoc markdown support
runtime(doc): In builtin overview use {buf} as param for
appendbufline/setbufline
runtime(doc): clarify, that register 1-* 9 will always be shifted
runtime(netrw): save and restore register 0-* 9, a and unnamed
runtime(termdebug): Refactored StartDebug_term and EndDebug
functions
runtime(java): Compose "g:java_highlight_signature" and
"g:java_highlight_functions"
* 9.1.0516: need more tests for nested dicts and list comparision
* 9.1.0515: Vim9: segfault in object_equal()
* 9.1.0514: Vim9: issue with comparing objects recursively
runtime(termdebug): Change some variables to Enums
runtime(vim): Update base-syntax, fix function tail comments
* 9.1.0513: Vim9: segfault with object comparison
- Update to 9.1.0512:
* Mode message for spell completion doesn't match allowed keys
* CursorMovedC triggered wrongly with setcmdpos()
* update runtime files
* CI: test_gettext fails on MacOS14 + MSVC Win
* not possible to translate Vim script messages
* termdebug plugin can be further improved
* add gomod filetype plugin
* hard to detect cursor movement in the command line
* Optionally highlight parameterised types
* filetype: .envrc & .prettierignore not recognized
* filetype: Faust files are not recognized
* inner-tag textobject confused about ">" in attributes
* cannot use fuzzy keyword completion
* Remove the group exclusion list from @javaTop
* wrong return type for execute() function
* MS-Windows: too much legacy code
* too complicated mapping restore in termdebug
* simplify mapping
* cannot switch buffer in a popup
* MS-Windows: doesn't handle symlinks properly
* getcmdcompltype() interferes with cmdline completion
* termdebug can be further improved
* update htmldjango detection
* Improve Turkish documentation
* include a simple csv filetype and syntax plugin
* include the the simple nohlsearch package
* matched text is highlighted case-sensitively
* Matched text isn't highlighted in cmdline pum
* Fix typos in several documents
* clarify when text properties are cleared
* improve the vim-shebang example
* revert unintended formatting changes for termdebug
* Add a config variable for commonly used compiler options
* Wrong matched text highlighted in pum with 'rightleft'
* bump length of character references in syntax script
* properly check mapping variables using null_dict
* fix KdlIndent and kdlComment in indent script
* Test for patch 9.1.0489 doesn't fail without the fix
* Fold multi-line comments with the syntax kind of &fdm
* using wrong type for PlaceSign()
* filetype: Vim-script files not detected by shebang line
* revert unintended change to zip#Write()
* add another tag for vim-shebang feature
* Cmdline pum doesn't work properly with 'rightleft'
* minor style problems with patch 9.1.0487
* default completion may break with fuzzy
* Wrong padding for pum "kind" with 'rightleft'
* Update base-syntax, match shebang lines
* MS-Windows: handle files with spaces properly
* Restore HTML syntax file tests
* completed item not update on fuzzy completion
* filetype: Snakemake files are not recognized
* make TermDebugSendCommand() a global function again
* close all buffers in the same way
* Matched text shouldn't be highlighted in "kind" and "menu"
* fix wrong helptag for :defer
* Update base-syntax, match :sleep arg
* include Georgian keymap
* Sorting of completeopt+=fuzzy is not stable
* correctly test for windows in NetrwGlob()
* glob() on windows fails with [] in directory name
* rewrite mkdir() doc and simplify {flags} meaning
* glob() not sufficiently tested
* update return type for job_info()
* termdebug plugin needs more love
* correct return types for job_start() and job_status()
* Update base-syntax, match :catch and :throw args
* Include element values in non-marker annotations
* Vim9: term_getjob() throws an exception on error
* fuzzy string matching executed when not needed
* fuzzy_match_str_with_pos() does unnecessary list operations
* restore description of "$" in col() and virtcol()
* deduplicate getpos(), line(), col(), virtcol()
* Update g:vimsyn_comment_strings dump file tests
* Use string interpolation instead of string concat
* potential deref of NULL pointer in fuzzy_match_str_with_pos
* block_editing errors out when using <enter>
* Update base-syntax, configurable comment string highlighting
* fix typos in syntax.txt
* Cannot see matched text in popup menu
* Update base-syntax, match multiline continued comments
* clarify documentation for "v" position at line()
* cmod_split modifier is always reset in term_start()
* remove line-continuation characters
* use shiftwidth() instead of &tabstop in indent script
* Remove orphaned screen dump files
* include syntax, indent and ftplugin files
* CI: Test_ColonEight() fails on github runners
* add missing Enabled field in syntax script
* basic svelte ftplugin file
* term_start() does not clear vertical modifier
* fix mousemodel restoration by comparing against null_string
* Added definitions of Vim scripts and plugins
* Exclude lambda expressions from _when_ _switch-case_ label clauses
* Fix saved_mousemodel check
* Inconsistencies between functions for option flags
* Crash when using autocmd_get() after removing event inside autocmd
* Fix small style issues
* add return type info for Vim function descriptions
* Update Italian Vim manpage
* disable the q mapping
* Change 'cms' for C++ to '// %s'
* fix type mismatch error
* Fix wrong email address
* convert termdebug plugin to Vim9 script
- Update to 9.1.0470:
* tests Test_ColonEight_MultiByte() fails sporadically
* Cannot have buffer-local value for 'completeopt'
* GvimExt does not consult HKEY_CURRENT_USER
* typos in some comments
* runtime(vim): Update base-syntax, allow whitespace before
:substitute pattern
* Missing comments for fuzzy completion
* runtime(man): update Vim manpage
* runtime(comment): clarify the usage of 'commentstring' option
value
* runtime(doc): clarify how fuzzy 'completeopt' should work
* runtime(netrw): prevent accidental data loss
* missing filecopy() function
* no whitespace padding in commentstring option in ftplugins
* no fuzzy-matching support for insert-completion
* eval5() and eval7 are too complex
* too many strlen() calls in drawline.c
* filetype lintstagedrc files are not recognized
* Vim9 import autoload does not work with symlink
* Coverity complains about division by zero
* tests test_gui fails on Wayland
* Left shift is incorrect with vartabstop and shiftwidth=0
* runtime(doc): clarify 'shortmess' flag "S"
* MS-Windows compiler warning for size_t to int conversion
* runtime(doc): include some vim9 script examples in the help
* minor issues in test_filetype with rasi test
* filetype rasi files are not recognized
* runtime(java): Improve the matching of lambda expressions
* Configure checks for libelf unnecessarily
* No test for escaping '<' with shellescape()
* check.vim complains about overlong comment lines
* translation(it): Update Italian translation
* evalc. code too complex
* MS-Windows Compiler warnings
- Update to 9.1.0448:
* compiler warning in eval.c
* remove remaining css code
* Add ft_hare.txt to Reference Manual TOC
* re-generate vim syntax from generator
* fix syntax vim bug
* completion may be wrong when deleting all chars
* getregionpos() inconsistent for partly-selected multibyte char
* fix highlighting nested and escaped quotes in string props
* remove the indent plugin since it has too many issues
* update Debian runtime files
* Coverity warning after 9.1.0440
* Not enough tests for getregion() with multibyte chars
* Can't use blockwise selection with width for getregion()
* update outdated syntax files
* fix floating_modifier highlight
* hare runtime files outdated
* getregionpos() can't properly indicate positions beyond eol
* function get_lval() is too long
* Cannot filter the history
* Wrong Ex command executed when :g uses '?' as delimiter
* support floating_modifier none; revert broken highlighting
* Motif requires non-const char pointer for XPM data
* Crash when using '?' as separator for :s
* filetype: cygport files are not recognized
* make errors trying to access autoload/zig
* Wrong yanking with exclusive selection and ve=all
* add missing help tags file
* Ancient XPM preprocessor hack may cause build errors
* include basic rescript ftplugin file
* eval.c is too long
* getregionpos() doesn't handle one char selection
* check for gdb file/dir before using as buffer name
* refactor zig ftplugin, remove auto format
* Coverity complains about eval.c refactor
* Tag guessing leaves wrong search history with very short names
* some issues with termdebug mapping test
* update matchit plugin to v1.20
* too many strlen() calls in search.c
* set commentstring option
* update vb indent plugin as vim9script
* filetype: purescript files are not recognized
* filetype: slint files are not recognized
* basic nim ftplugin file for comments
* Add Arduino ftplugin and indent files
* include basic typst ftplugin file
* include basic prisma ftplugin file
* include basic v ftplugin for comment support
* getregionpos() wrong with blockwise mode and multibyte
* function echo_string_core() is too long
* hyprlang files are not recognized
* add basic dart ftplugin file
* basic ftplugin file for graphql
* mention comment plugin at :h 'commentstring'
* set commentstring for sql files in ftplugin
* :browse oldfiles prompts even with single entry
* eval.c not sufficiently tested
* clarify why E195 is returned
* clarify temporary file clean up
* fix :NoMatchParen not working
* Cannot move to previous/next rare word
* add basic ftplugin file for sshdconfig
* if_py: find_module has been removed in Python 3.12.0a7
* some screen dump tests can be improved
* Some functions are not tested
* clarify instal instructions for comment package
* Unable to leave long line with 'smoothscroll' and 'scrolloff'
* fix typo in vim9script help file
* Remove trailing spaces
* clarify {special} argument for shellescape()
- update to 9.1.0413
* smoothscroll may cause infinite loop
* add missing entries for the keys CTRL-W g<Tab> and <C-Tab>
* update vi_diff.txt: add default value for 'flash'
* typo in regexp_bt.c in DEBUG code
* allow indented commands
* Fix wrong define regex in ftplugin
* Filter out non-Latin-1 characters for syntax tests
* prefer scp over pscp
* fix typo in usr_52.txt
* too long functions in eval.c
* warning about uninitialized variable
* too many strlen() calls in the regexp engine
* E16 fix, async keyword support for define
* Stuck with long line and half-page scrolling
* Divide by zero with getmousepos() and 'smoothscroll'
* update and remove some invalid links
* update translation of xxd manpage
* Recursively delete directories by default with netrw delete command
* Strive to remain compatible for at least Vim 7.0
* tests: xxd buffer overflow fails on 32-bit
* Stop handpicking syntax groups for @javaTop
* [security] xxd: buffer-overflow with specific flags
* Vim9: not able to import file from start dir
* filetype: mdd files detected as zsh filetype
* filetype: zsh module files are not recognized
* Remove hardcoded private.ppk logic from netrw
* Vim9: confusing error message for unknown type
* block_editing errors out when using del
* add new items to scripts section in syntax plugin
* Vim9: imported vars are not properly type checked
* Wrong display with 'smoothscroll' when changing quickfix list
* filetype: jj files are not recognized
* getregionpos() may leak memory on error
* The CODEOWNERS File is not useful
* Remove and cleanup Win9x legacy from netrw
* add MsgArea to 'highlight' option description
* Cannot get a list of positions describing a region
* Fix digit separator in syntax script for octals and floats
* Update link to Wikipedia Vi page
* clear $MANPAGER in ftplugin before shelling out
* Fix typos in help documents
* 'viewdir' not respecting $XDG_CONFIG_HOME
* tests: Vim9 debug tests may be flaky
* correct getscriptinfo() example
* Vim9: could improve testing
* test_sound fails on macos-12
* update Serbian menu
* update Slovak menu
* update Slovenian menu
* update Portuguese menu
* update Dutch menu
* update Korean menu
* update Icelandic menu
* update Czech menu
* update Afrikaans menu
* update German menu
* filetype: inko files are not recognized
* filetype: templ files are not recognized
* cursor() and getregion() don't handle v:maxcol well
* Vim9: null value tests not sufficient
* update Catalan menu
* filetype: stylus files not recognized
* update spanish menu localization
* regenerate helptags
* Vim9: crash with null_class and null_object
* Add tags about lazyloading of menu
* tests: vt420 terminfo entry may not be found
* filetype: .out files recognized as tex files
* filetype: Kbuild files are not recognized
* cbuffer and similar commands don't accept a range
* Improve the recognition of the "indent" method declarations
* Fix a typo in usr_30.txt
* remove undefined var s:save_cpoptions and add include setting
* missing setlocal in indent plugin
* Calculating line height for unnecessary amount of lines
* improve syntax file performance
* There are a few typos
* Vim9: no comments allowed after class vars
* CI: remove trailing white space in documentation
* Formatting text wrong when 'breakindent' is set
* Add oracular (24.10) as Ubuntu release name
* Vim9: Trailing commands after class/enum keywords ignored
* tests: 1-second delay after Test_BufEnter_botline()
* update helptags for jq syntax
* include syntax, ftplugin and compiler plugin
* fix typo synconcealend -> synconcealed
* include a simple comment toggling plugin
* wrong botline in BufEnter
* clarify syntax vs matching mechanism
* fix undefined variable in indent plugin
* ops.c code uses too many strlen() calls
* Calling CLEAR_FIELD() on the same struct twice
* Vim9: compile_def_function() still too long
* Update Serbian messages
* clarify the effect of setting the shell to powershell
* Improve the recognition of the "style" method declarations
* Vim9: problem when importing autoloaded scripts
* compile_def_function is too long
* filetype: ondir files are not recognized
* Crash when typing many keys with D- modifier
* tests: test_vim9_builtin is a bit slow
* update documentation
* change the download URL of "libsodium"
* tests: test_winfixbuf is a bit slow
* Add filetype, syntax and indent plugin for Astro
* expanding rc config files does not work well
* Vim9: vim9type.c is too complicated
* Vim9: does not handle autoloaded variables well
* minor spell fix in starting.txt
* wrong drawing in GUI with setcellwidth()
* Add include and suffixesadd
* Page scrolling should place cursor at window boundaries
* align command line table
* minor fixes to starting.txt
* fix comment definition in filetype plugin
* filetype: flake.lock files are not recognized
* runtime(uci): No support for uci file types
* Support "g:ftplugin_java_source_path" with archived files
* tests: Test_autoload_import_relative_compiled fails on Windows
* Finding cmd modifiers and cmdline-specials is inefficient
* No test that completing a partial mapping clears 'showcmd'
* tests: test_vim9_dissamble may fail
* Vim9: need static type for typealias
* X11 does not ignore smooth scroll event
* A few typos in test_xdg when testing gvimrc
* Patch v9.1.0338 fixed sourcing a script with import
* Problem: gvimrc not sourced from XDG_CONFIG_HOME
* Cursor wrong after using setcellwidth() in terminal
* 'showcmd' wrong for partial mapping with multibyte
* tests: test_taglist fails when 'helplang' contains non-english
* Problem: a few memory leaks are found
* Problem: Error with matchaddpos() and empty list
* tests: xdg test uses screen dumps
* Vim9: import through symlinks not correctly handled
* Missing entry for XDG vimrc file in :version
* tests: typo in test_xdg
* runtime(i3config/swayconfig): update syntax scripts
* document pandoc compiler and enable configuring arguments
* String interpolation fails for List type
* No test for highlight behavior with 'ambiwidth'
* tests: test_xdg fails on the appimage repo
* tests: some assert_equal() calls have wrong order of args
* make install does not install all files
* runtime(doc): fix typos in starting.txt
- Remove patch to fix bsc#1220618:
* vim-8.2.3607-revert-gtk3-code-removal.patch
- This patch introduced this bug that caused Vim to use significantly more CPU.
- Updated to version 9.1 with patch level 0330, fixes the following problems
* Fixing bsc#1220763 - vim gets Segmentation fault after updating to version 9.1.0111-150500.20.9.1
- refreshed vim-7.3-filetype_spec.patch
- refreshed vim-7.3-filetype_ftl.patch
- Update spec.skeleton to use autosetup in place of setup macro.
- for the complete list of changes see
https://github.com/vim/vim/compare/v9.1.0111...v9.1.0330
- Updated to version 9.1 with patch level 0111, fixes the following security problems
* Fixing bsc#1217316 (CVE-2023-48231) - VUL-0: CVE-2023-48231: vim: Use-After-Free in win_close()
* Fixing bsc#1217320 (CVE-2023-48232) - VUL-0: CVE-2023-48232: vim: Floating point Exception in adjust_plines_for_skipcol()
* Fixing bsc#1217321 (CVE-2023-48233) - VUL-0: CVE-2023-48233: vim: overflow with count for :s command
* Fixing bsc#1217324 (CVE-2023-48234) - VUL-0: CVE-2023-48234: vim: overflow in nv_z_get_count
* Fixing bsc#1217326 (CVE-2023-48235) - VUL-0: CVE-2023-48235: vim: overflow in ex address parsing
* Fixing bsc#1217329 (CVE-2023-48236) - VUL-0: CVE-2023-48236: vim: overflow in get_number
* Fixing bsc#1217330 (CVE-2023-48237) - VUL-0: CVE-2023-48237: vim: overflow in shift_line
* Fixing bsc#1217432 (CVE-2023-48706) - VUL-0: CVE-2023-48706: vim: heap-use-after-free in ex_substitute
* Fixing bsc#1219581 (CVE-2024-22667) - VUL-0: CVE-2024-22667: vim: stack-based buffer overflow in did_set_langmap function in map.c
* Fixing bsc#1215005 (CVE-2023-4750) - VUL-0: CVE-2023-4750: vim: Heap use-after-free in function bt_quickfix
- Revert the patch which caused GTK incompatibility problem
* Add: vim-9.1-revert-v9.1.86.patch
* This reverts commit 725c7c31a4c7603e688511d769b0addaab442d07
- for the complete list of changes see
https://github.com/vim/vim/compare/v9.0.2103...v9.1.0111
- Updated to version 9.0 with patch level 2103, fixes the following security problems
* Fixing bsc#1215940 (CVE-2023-5344) - VUL-0: CVE-2023-5344: vim: Heap-based Buffer Overflow in vim prior to 9.0.1969.
* Fixing bsc#1216001 (CVE-2023-5441) - VUL-0: CVE-2023-5441: vim: segfault in exmode when redrawing
* Fixing bsc#1216167 (CVE-2023-5535) - VUL-0: CVE-2023-5535: vim: use-after-free from buf_contents_changed()
* Fixing bsc#1216696 (CVE-2023-46246) - VUL-0: CVE-2023-46246: vim: Integer Overflow in :history command
- for the complete list of changes see
https://github.com/vim/vim/compare/v9.0.1894...v9.0.2103
Package ca-certificates was updated:
Package gnutls was updated:
- Fix 1-byte heap buffer overflow when parsing templates with certtool [bsc#1246267, CVE-2025-32990]
* Add patch gnutls-CVE-2025-32990.patch
- 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 icu was updated:
- Add icu-CVE-2025-5222.patch: Backport 2c667e3 from upstream, ICU-22973 Fix buffer overflow by
using CharString.
(CVE-2025-5222, bsc#1243721)
- Add icu-CVE-2025-5222-shim06_9e4365c.patch
Backport 9e4365c from upstream, ICU-10810 genrb: preflight strings
on final parse tree, not while building the tree. To prepare
dependence code for CVE-2025-5222 fix.
(CVE-2025-5222, bsc#1243721)
- Add icu-CVE-2025-5222-shim05_7496867.patch:
Backport 7496867 from markusicu upstream, which is tree merged to
icu. ICU-9101 build all source/data/coll/ tailorings, except
search, with new CollationBuilder. To prepare dependence code for
CVE-2025-5222 fix.
(CVE-2025-5222, bsc#1243721)
- Add icu-CVE-2025-5222-shim04_8067293.patch:
Backport 8067293 from upstream, ICU-10043 ignore the genrb
- -omitCollationRules flag while importing rules. To prepare
dependence code for CVE-2025-5222 fix.
(CVE-2025-5222, bsc#1243721)
- Add icu-CVE-2025-5222-shim03-dd72356.patch:
Backport dd72356 from upstream, ICU-11276 Adding UChar* method in
CharString. To prepare dependence code for CVE-2025-5222 fix.
(CVE-2025-5222, bsc#1243721)
- Add icu-CVE-2025-5222-shim02_80a6684.patch:
Backport 80a6684 from upstream, ICU-11794 change error handling
of CharString::appendInvariantChars(). To prepare dependence code
for CVE-2025-5222 fix.
(CVE-2025-5222, bsc#1243721)
- Add icu-CVE-2025-5222-shim01.patch:
Include stringpiece.h charstr.h for following source porting. To
prepare dependence code for CVE-2025-5222 fix.
(CVE-2025-5222, bsc#1243721)
Package kernel-default was updated:
- wifi: ath9k: hif_usb: fix memory leak of remain_skbs (CVE-2023-53641 bsc#1251728)- commit cddd1eb
- thermal: intel_powerclamp: Use first online CPU as control_cpu (bsc#1251173)
- commit a5e3566
- thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash (CVE-2022-50494 bsc#1251173)
- commit 2222fc8
- drm/scheduler: signal scheduled fence when kill job (bsc#1247227 CVE-2025-38436)
- commit b828f36
- Update
patches.suse/tcp-Don-t-call-reqsk_fastopen_remove-in-tcp_conn_request.patch
(git-fixes CVE-2025-40186 bsc#1253438).
- commit f901ef4
- net: dcb: choose correct policy to parse DCB_ATTR_BCN (CVE-2023-53369 bsc#1250206)
- commit 358246e
- btrfs: avoid potential out-of-bounds in btrfs_encode_fh() (CVE-2025-40205 bsc#1253456)
- commit 22c9af2
- net/ip6_tunnel: Prevent perpetual tunnel growth (CVE-2025-40173
bsc#1253421).
- commit d8c4c44
- scsi: mvsas: Fix use-after-free bugs in mvs_work_queue
(CVE-2025-40001 bsc#1252303).
- commit bb0f1cb
- uio_hv_generic: Let userspace take care of interrupt mask (CVE-2025-40048 bsc#1252862).
- commit 76a0e50
- sctp: Fix MAC comparison to be constant-time (CVE-2025-40204
bsc#1253436).
- commit eccee08
- smb3: fix Open files on server counter going negative
(git-fixes).
- commit 15583ca
- cifs: return a single-use cfid if we did not get a lease
(bsc#1228688).
- commit c039524
- cifs: Check the lease context if we actually got a lease
(bsc#1228688).
- Refresh
patches.suse/cifs-fix-open-leaks-in-open_cached_dir.patch.
- Refresh
patches.suse/smb-client-fix-potential-OOBs-in-smb2_parse_contexts-.patch.
- commit 9351453
- kabi/severities: Update info about kvm_86_ops
- commit 69450ab
- net/sched: sch_qfq: Fix null-deref in agg_dequeue (CVE-2025-40083 bsc#1252912).
- commit 2a85e50
- KVM: x86: Give a hint when Win2016 might fail to boot due to XSAVES erratum (git-fixes).
- commit 4d19df5
- Refresh patches.suse/x86-CPU-AMD-Disable-XSAVES-on-AMD-family-0x17.patch.
XSAVE feature clearing should apply to ZEN1/2 and not to K6 CPUs.
- commit b258ad9
- blacklist.conf: Add imxfb commit
- Delete
patches.suse/0002-video-fbdev-imxfb-Fix-an-error-message.patch.
- Delete
patches.suse/0004-fbdev-imxfb-warn-about-invalid-left-right-margin.patch.
We don't build this driver.
- commit a556fb5
- net/sched: sch_hfsc: upgrade 'rt' to 'sc' when it becomes a
inner curve (bsc#1220419).
- commit 6275dfe
- scsi: ses: Handle enclosure with just a primary component
gracefully (git-fixes CVE-2023-53431 bsc#1250374).
- commit 1585d41
- PCI: aardvark: Fix checking for MEM resource type (git-fixes).
- commit ee4989d
- Fix another type-mismatch issue in fbcon patches (bsc#1252033 CVE-2025-39967 bsc#1253237)
Fix another type mismatch in fbcon font handling:
* comparison of distinct pointer types lacks a cast [enabled by default] in ../drivers/video/console/fbcon.c in fbcon_set_font (from ../include/linux/overflow.h)
In file included from ../include/linux/vmalloc.h:10:0,
../drivers/video/console/fbcon.c: In function 'fbcon_set_font':
../include/linux/overflow.h:150:15: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../include/linux/overflow.h:206:4: note: in expansion of macro '__signed_add_overflow'
../drivers/video/console/fbcon.c:2467:6: note: in expansion of macro 'check_add_overflow'
* comparison of distinct pointer types lacks a cast [enabled by default] in ../include/linux/overflow.h
../include/linux/overflow.h:151:15: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../include/linux/overflow.h:206:4: note: in expansion of macro '__signed_add_overflow'
../drivers/video/console/fbcon.c:2467:6: note: in expansion of macro 'check_add_overflow'
* comparison of distinct pointer types lacks a cast [enabled by default] in ../include/linux/overflow.h
../include/linux/overflow.h:101:15: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../include/linux/overflow.h:207:4: note: in expansion of macro '__unsigned_add_overflow'
../drivers/video/console/fbcon.c:2467:6: note: in expansion of macro 'check_add_overflow'
* comparison of distinct pointer types lacks a cast [enabled by default] in ../include/linux/overflow.h
../include/linux/overflow.h:102:15: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../include/linux/overflow.h:207:4: note: in expansion of macro '__unsigned_add_overflow'
../drivers/video/console/fbcon.c:2467:6: note: in expansion of macro 'check_add_overflow'
- commit 3586116
- Refresh
patches.suse/KVM-nSVM-always-intercept-VMLOAD-VMSAVE-when-nested.
- Refresh
patches.suse/KVM-nSVM-avoid-picking-up-unsupported-bits-from-L2-i.
Add upstream commit ID and move to sorted section.
- commit 808b040
- dmaengine: bcm2835: Avoid GFP_KERNEL in device_prep_slave_sg
(bsc#1070872).
Rename, update with upstream description and reference, and move to the
sorted section.
- commit 3ac835f
- Move ocfs2 fixes to the sorted section
- commit c36ff63
- wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta (CVE-2023-53229 bsc#1249650)
- commit 6e55df1
- Restore fixes for fbcon_do_set_font() (bsc#1252033 CVE-2025-39967 bsc#1253237)
The backport from bsc#1252033 failed because check_mul_overflow()
did not handle differences in type signs. Restore the patches and
fix them to use unsigned types for all calculations. Input arguments
are unsigned anyway.
- commit 7a71d84
- wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request() (CVE-2022-50551 bsc#1251322)
- commit 644642c
- r6040: Fix kmemleak in probe and remove (CVE-2022-50545 bsc#1251285)
- commit 506400a
- xfrm: Update ipcomp_scratches with NULL when freed
(CVE-2022-50569 bsc#1252640).
- commit 8b98d1b
- scsi: target: iscsi: Fix buffer overflow in
lio_target_nacl_info_show() (bsc#1251786 CVE-2023-53676).
- commit e9a3dc4
- Revert "fbcon: fix integer overflow in fbcon_do_set_font (bsc#1252033 CVE-2025-39967)"
This reverts commit ef5b27e0395e36f32d5881894b4deb2dc992343a.
- commit 541fc90
- Revert "fbcon: Fix OOB access in font allocation (bsc#1252033)"
This reverts commit d696663168f05fd9eb1b90bb1be489edf7001e6b.
- commit 3f75577
- Alt-commit updates
- Refresh
patches.suse/0001-drm-amdgpu-validate-the-parameters-of-bo-mapping-ope.patch.
- Refresh
patches.suse/0001-drm-i915-gem-Fix-Virtual-Memory-mapping-boundaries-c.patch.
- Refresh patches.suse/1394-drm-msm-fix-no_implicit-fencing-case.
- Refresh
patches.suse/Revert-drm-radeon-Fix-EEH-during-kexec.patch.
- commit 5d5cec6
- ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy (CVE-2023-53542 bsc#1251154)
- commit f3fb811
- drm/msm/dsi: fix memory corruption with too many bridges (CVE-2022-50368 bsc#1250009)
- commit 520589a
- pps: fix warning in pps_register_cdev when register device fail
(CVE-2025-40070 bsc#1252836).
- commit cb71ffd
- pinctrl: check the return value of
pinmux_ops::get_function_name() (CVE-2025-40030 bsc#1252773).
- commit b26cdf3
- ocfs2: fix double free in user_cluster_connect() (CVE-2025-40055 bsc#1252821)
- commit 832b986
- class: fix possible memory leak in __class_register()
(CVE-2022-50578 bsc#1252519).
- commit 4001512
- mm/ksm: fix flag-dropping behavior in ksm_madvise
(CVE-2025-40040 bsc#1252780).
- commit 6af1ea3
- net/9p: fix double req put in p9_fd_cancelled (CVE-2025-40027
bsc#1252763).
- commit 12bcbd0
- fs/smb: Fix inconsistent refcnt update (bsc#1250176,
CVE-2025-39819).
- commit 8b09411
- 9p/trans_fd: Fix concurrency del of req_list in
p9_fd_cancelled/p9_read_work (CVE-2025-40027 bsc#1252763).
- commit 2d2d005
- cifs: fix mid leak during reconnection after timeout threshold
(bsc#1251159, CVE-2023-53597).
- commit 29af9dd
- tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails
to allocate psock->cork (bsc#1250705).
- commit 5eef25f
- tcp_bpf: Fix copied value in tcp_bpf_sendmsg (bsc#1250650).
- skmsg: Return copied bytes in sk_msg_memcopy_from_iter
(bsc#1250650).
- commit 7274f26
- wifi: ath9k: Fix potential stack-out-of-bounds write in
ath9k_wmi_rsp_callback() (CVE-2023-53717 bsc#1252560).
- commit 469787a
- net: sched: cls_u32: Undo tcf_bind_filter if
u32_replace_hw_knode (CVE-2023-53733 bsc#1252685).
- commit 308a4a1
- blacklist.conf: CVE-2025-37928 bsc#1243621
- Delete patches.suse/dm-bufio-don-t-schedule-in-atomic-context.patch
- commit 2991827
- udf: Preserve link count of system files (bsc#1252539
CVE-2023-53695).
- commit c7818f7
- udf: Detect system inodes linked into directory hierarchy
(bsc#1252539 CVE-2023-53695).
- commit 9e1ad9a
- NFSD: Define a proc_layoutcommit for the FlexFiles layout type
(CVE-2025-40088 bsc#1252909).
- commit b682724
- hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
(CVE-2025-40082 bsc#1252775).
- commit 71ba5db
- hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()
(CVE-2025-40088 bsc#1252904).
- commit 3401643
- kernel-subpackage-spec: Do not doubly-sign modules (bsc#1251930).
- commit 0f034b6
- bpf: Explicitly check accesses to bpf_sock_addr (CVE-2025-40078
bsc#1252789).
- commit 62aaf66
- Squashfs: fix uninit-value in squashfs_get_parent (bsc#1252822
CVE-2025-40049).
- commit acc9cea
- fs: udf: fix OOB read in lengthAllocDescs handling (bsc#1252785 CVE-2025-40044).
- commit 7dc17e9
- drm/amdkfd: Fix UBSAN shift-out-of-bounds warning (bsc#1250764 CVE-2021-4460)
- commit 033f866
- pnode: terminate at peers of source (CVE-2022-50280 bsc#1249806)
- commit 628cc9e
- crypto: af_alg - Set merge to zero early in af_alg_sendmsg (CVE-2025-39931 bsc#1251100).
- commit 904e401
- btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure (CVE-2022-50571 bsc#1252487)
- commit 8e09358
- drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 (bsc#1252632 CVE-2023-53707)
- commit 73d1a0a
- Update
patches.suse/0086-dm-thin-Fix-UAF-in-run_timer_softirq.patch
(git-fixes CVE-2022-50563 bsc#1252480).
- Update patches.suse/hfs-fix-OOB-Read-in-__hfs_brec_find.patch
(git-fixes CVE-2022-50581 bsc#1252549).
- Update
patches.suse/md-raid1-fix-potential-OOB-in-raid1_remove_disk-8b04.patch
(git-fixes CVE-2023-53722 bsc#1252499).
- Update
patches.suse/s390-netiucv-Fix-return-type-of-netiucv_tx.patch
(git-fixes bsc#1212175 CVE-2022-50564 bsc#1252538).
- Update
patches.suse/scsi-qla2xxx-Fix-memory-leak-in-qla2x00_probe_one.patch
(git-fixes CVE-2023-53696 bsc#1252513).
- Update
patches.suse/scsi-ses-Fix-possible-addl_desc_ptr-out-of-bounds-accesses.patch
(git-fixes CVE-2023-7324 bsc#1252893).
- commit 6722787
- fbcon: Fix OOB access in font allocation (bsc#1252033)
- commit d696663
- fbcon: fix integer overflow in fbcon_do_set_font (bsc#1252033 CVE-2025-39967)
- commit ef5b27e
- kABI fix for net: vlan: fix VLAN 0 refcount imbalance of
toggling filtering during runtime (CVE-2025-38470 bsc#1247288).
- commit 589d82f
- i2c: mux: reg: check return value after calling platform_get_resource() (CVE-2022-50364 bsc#1250083)
- commit 2b2cffb
- ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free
(CVE-2025-39997 bsc#1252056).
- commit a51d8e6
- iommu/amd: Fix pci device refcount leak in ppr_notifier() (CVE-2022-50505 bsc#1251086)
- commit 8687154
- drm/hisilicon/hibmc: fix the hibmc loaded failed bug (CVE-2025-39772 bsc#1249506)
- commit d8e1da7
- ipvs: Defer ip_vs_ftp unregister during netns cleanup
(CVE-2025-40018 bsc#1252688).
- commit 69275ca
- ext4: fix bug in extents parsing when eh_entries == 0 and
eh_depth > 0 (bsc#1223475 CVE-2022-48631).
- commit 70236d6
- tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request()
(git-fixes).
- commit 757a6b5
- tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect()
(CVE-2025-39955 bsc#1251804).
- ipv6: Fix out-of-bounds access in ipv6_find_tlv()
(CVE-2023-53705 bsc#1252554).
- commit 171d7f3
- Revert "e1000e: fix heap overflow in e1000_set_eeprom (CVE-2025-39898"
This reverts commit 2836e8d8d652cc9b552b6399525f14e15353483b.
- commit 0a9731b
- Revert "Refresh"
This reverts commit 9531965fe99a2d5cc7f092699c30780cd95fe9e3.
- Revert "Refresh"
This reverts commit bbde1b2cc3e31ca5dab4e71e08f50d277c0dcf13.
- commit 1af8647
- md: fix soft lockup in status_resync (bsc1251318,
CVE-2023-53620).
- commit 8f3ae24
- i40e: add max boundary check for VF filters (CVE-2025-39968
bsc#1252047).
- i40e: fix idx validation in i40e_validate_queue_map
(CVE-2025-39972 bsc#1252039).
- i40e: add validation for ring_len param (CVE-2025-39973
bsc#1252035).
- qed: Don't collect too many protection override GRC elements
(CVE-2025-39949 bsc#1251177).
- commit bc08ffd
- lib: cpu_rmap: Fix potential use-after-free in
irq_cpu_rmap_release() (CVE-2023-53484 bsc#1250895).
- commit d30b615
- lib: cpu_rmap: Avoid use after free on rmap->obj array entries
(CVE-2023-53484 bsc#1250895).
- commit 3aa6f20
- wifi: cfg80211: reject auth/assoc to AP with our address
(CVE-2023-53540 bsc#1251053).
- commit ee3b008
- wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex
(CVE-2023-53715 bsc#1252545).
- commit 9b29c92
- i40e: fix idx validation in config queues msg (CVE-2025-39971 bsc#1252052)
- commit c33db33
- i40e: Add bounds check for ch[] array (CVE-2025-39971 bsc#1252052)
- commit bf307ec
- i40e: fix input validation logic for action_meta (CVE-2025-39970 bsc#1252051)
- commit 4e82f01
- i40e: Fix filter input checks to prevent config with invalid values (CVE-2025-39970 bsc#1252051)
- commit 57297d8
- net: sched: sfb: fix null pointer access issue when sfb_init()
fails (CVE-2022-50356 bsc#1250040).
- commit 882fd64
- tty: serial: samsung_tty: Fix a memory leak in
s3c24xx_serial_getclk() when iterating clk (CVE-2023-53687
bsc#1251772).
- commit 653cf6a
- cifs: Release folio lock on fscache read hit (CVE-2023-53593 bsc#1251132)
- commit 6362ac3
- dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees (CVE-2025-39923 bsc#1250741)
- commit fbf8fb9
- net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() (CVE-2025-39876 bsc#1250400)
- commit bd6ed1f
- net: hv_netvsc: fix loss of early receive events from host during channel open (bsc#1252265).
- commit e2ece38
- netfilter: conntrack: fix wrong ct->timeout value
(CVE-2023-53635 bsc#1251524).
- commit cb2dbc3
- scsi: iscsi_tcp: Check that sock is valid before
iscsi_set_param() (git-fixes).
- commit f85971b
- Refresh
patches.suse/e1000e-fix-heap-overflow-in-e1000_set_eeprom.patch.
Let check_add_overflow perform its intended duty.
- commit bbde1b2
- smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path (CVE-2025-39929 bsc#1251036)
- commit 33a9326
- i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path (CVE-2025-39911 bsc#1250704)
- commit 18ff544
- sctp: initialize more fields in sctp_v6_from_sk() (CVE-2025-39812 bsc#1250202)
- commit 262d224
- integrity: Fix memory leakage in keyring allocation error path (CVE-2022-50395 bsc#1250211)
- commit 89f3524
- memory: of: Fix refcount leak bug in of_get_ddr_timings() (CVE-2022-50249 bsc#1249747)
- commit a04f0d4
- openvswitch: fix lockup on tx to unregistering netdev with carrier (bsc#1249854)
- commit 5c8a374
- net: openvswitch: fix race on port output (CVE-2023-53188 bsc#1249854)
- commit 02a1cae
- ipv6: sr: Fix MAC comparison to be constant-time (CVE-2025-39702 bsc#1249317)
- commit 6728b5c
- sctp: linearize cloned gso packets in sctp_rcv (CVE-2025-38718 bsc#1249161)
- commit 084aea4
- serial: 8250: fix panic due to PSLVERR (CVE-2025-39724 bsc#1249265)
- commit 9d4bd1b
- scsi: qla4xxx: Prevent a potential error pointer dereference (CVE-2025-39676 bsc#1249302)
- commit a7b1238
- media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() (CVE-2025-38680 bsc#1249203)
- commit c6c8afe
- scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling
getpeername() (CVE-2022-50459 bsc#1250850).
- commit 3807688
- blk-mq: fix NULL dereference on q->elevator in
blk_mq_elv_switch_none (CVE-2023-53292 bsc#1250163).
- blk-mq: protect q->elevator by ->sysfs_lock in
blk_mq_elv_switch_none (CVE-2023-53292 bsc#1250163).
- commit f60e1b9
- netfilter: conntrack: Avoid nf_ct_helper_hash uses after free
(CVE-2023-53619 bsc#1251743).
- commit d9a3ca9
- NFSv4.1: fix backchannel max_resp_sz verification check
(bsc#1247518).
- commit 4f042cf
- doc/README.SUSE: Correct the character used for TAINT_NO_SUPPORT
The character was previously 'N', but upstream used it for TAINT_TEST,
which prompted the change of TAINT_NO_SUPPORT to 'n'. This occurred in
commit c35dc3823d08 ("Update to 6.0-rc1") on master and in d016c04d731d
("Bump to 6.4 kernel (jsc#PED-4593)") for SLE15-SP6 (and onwards).
Update the documentation to reflect this change.
- commit f42ecf5
- ALSA: ac97: Fix possible error value of *rac97 (CVE-2023-53648
bsc#1251750).
- ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer
(CVE-2023-53648 bsc#1251750).
- commit 3add5a8
- tipc: add tipc_bearer_min_mtu to calculate min mtu
(CVE-2023-53517 bsc1250919).
- commit af0b7c0
- tipc: do not update mtu if msg_max is too small in mtu
negotiation (CVE-2023-53517 bsc#1250919).
- commit 246819a
- btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range (CVE-2022-50293 bsc#1249752)
- commit 674444e
- btrfs: exit gracefully if reloc roots don't match (CVE-2023-53183 bsc#1249863)
- commit 5aefca3
- btrfs: fix BUG_ON condition in btrfs_cancel_balance (CVE-2023-53339 bsc#1250329)
- commit e64f98a
- hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
(bsc#1249260 CVE-2025-38714).
- commit d550dcb
- nfsd: handle get_client_locked() failure in
nfsd4_setclientid_confirm() (bsc#1249169 CVE-2025-38724).
- commit 7ce8b22
- net/sched: sch_fq: fix integer overflow of "credit"
(CVE-2023-53624 bsc#1251333).
- commit 4033336
- pNFS: Fix uninited ptr deref in block/scsi layout (bsc#1249215
CVE-2025-38691).
- commit b3165ea
- Update
patches.suse/0003-fbdev-omapfb-lcd_mipid-Fix-an-error-handling-path-in.patch
(bsc#1154048 CVE-2023-53650 bsc#1251283).
- Update patches.suse/0087-dm-cache-Fix-UAF-in-destroy.patch
(git-fixes CVE-2022-50496 bsc#1251091).
- Update
patches.suse/0088-dm-thin-Fix-ABBA-deadlock-between-shrink_slab-and-dm_pool_abort_metadata.patch
(git-fixes CVE-2022-50549 bsc#1251550).
- Update
patches.suse/0092-dm-thin-Use-last-transaction-s-pmd-root-when-commit-failed.patch
(git-fixes CVE-2022-50534 bsc#1251292).
- Update
patches.suse/Input-raspberrypi-ts-fix-refcount-leak-in-rpi_ts_pro.patch
(git-fixes CVE-2023-53533 bsc#1251080).
- Update
patches.suse/NFSD-Protect-against-send-buffer-overflow-in-NFSv3-Rdir.patch
(bsc#1205128 CVE-2022-43945 bsc#1210124 CVE-2022-50487
bsc#1251208).
- Update
patches.suse/bcache-Fix-__bch_btree_node_alloc-to-make-the-failur-80fc.patch
(git-fixes CVE-2023-53681 bsc#1251769).
- Update
patches.suse/bpf-sockmap-Fix-repeated-calls-to-sock_put-when-msg-.patch
(bsc#1235485 CVE-2024-56633 CVE-2022-50536 bsc#1251293).
- Update
patches.suse/btrfs-output-extra-debug-info-if-we-failed-to-find-a.patch
(bsc#1215136 CVE-2023-53672 bsc#1251780).
- Update
patches.suse/dm-integrity-call-kmem_cache_destroy-in-dm_integrity-6b79.patch
(git-fixes CVE-2023-53604 bsc#1251210).
- Update
patches.suse/firmware-raspberrypi-fix-possible-memory-leak-in-rpi.patch
(git-fixes CVE-2022-50537 bsc#1251294).
- Update
patches.suse/fs-hfsplus-remove-WARN_ON-from-hfsplus_cat_-read-write-_inode.patch
(git-fixes CVE-2023-53683 bsc#1251329).
- Update
patches.suse/gfs2-Fix-possible-data-races-in-gfs2_show_options.patch
(git-fixes CVE-2023-53622 bsc#1251777).
- Update
patches.suse/ipmi-Cleanup-oops-on-initialization-failure.patch
(FATE#326156 CVE-2023-53611 bsc#1251123).
- Update
patches.suse/media-coda-Add-check-for-dcoda_iram_alloc.patch
(git-fixes CVE-2022-50501 bsc#1251099).
- Update patches.suse/media-coda-Add-check-for-kmalloc.patch
(git-fixes CVE-2022-50509 bsc#1251522).
- Update patches.suse/media-radio-shark-Add-endpoint-checks.patch
(git-fixes CVE-2023-53644 bsc#1251736).
- Update
patches.suse/msft-hv-2870-Drivers-hv-vmbus-Don-t-dereference-ACPI-root-object-.patch
(git-fixes CVE-2023-53647 bsc#1251732).
- Update
patches.suse/net-cdc_ncm-Deal-with-too-low-values-of-dwNtbOutMaxS.patch
(git-fixes CVE-2023-53667 bsc#1251761).
- Update
patches.suse/ocfs2-fix-defrag-path-triggering-jbd2-ASSERT.patch
(git-fixes CVE-2023-53564 bsc#1251072).
- Update
patches.suse/powerpc-rtas-avoid-scheduling-in-rtas_os_term.patch
(bsc#1065729 CVE-2022-50504 bsc#1251182).
- Update
patches.suse/ring-buffer-Fix-deadloop-issue-on-reading-trace_pipe.patch
(git-fixes CVE-2023-53668 bsc#1251286).
- Update
patches.suse/ring-buffer-Sync-IRQ-works-before-buffer-destruction.patch
(git-fixes CVE-2023-53587 bsc#1251128).
- Update
patches.suse/s390-zcrypt-don-t-leak-memory-if-dev_set_name-fails.patch
(git-fixes bsc#1215152 CVE-2023-53568 bsc#1251035).
- Update
patches.suse/scsi-mpt3sas-Fix-possible-resource-leaks-in-mpt3sas_transport_port_add.patch
(git-fixes CVE-2022-50532 bsc#1251300).
- Update
patches.suse/scsi-qla2xxx-Avoid-fcport-pointer-dereference.patch
(bsc#1213747 CVE-2023-53603 bsc#1251180).
- Update
patches.suse/scsi-qla2xxx-Fix-crash-when-I-O-abort-times-out.patch
(jsc#PED-568 CVE-2022-50493 bsc#1251088).
- Update
patches.suse/scsi-qla2xxx-Fix-deletion-race-condition.patch
(bsc#1213747 CVE-2023-53615 bsc#1251113).
- Update
patches.suse/scsi-ses-Fix-possible-desc_ptr-out-of-bounds-accesses.patch
(git-fixes CVE-2023-53675 bsc#1251325).
- Update
patches.suse/usb-host-xhci-Fix-potential-memory-leak-in-xhci_allo.patch
(git-fixes CVE-2022-50544 bsc#1251725).
- Update
patches.suse/xhci-Remove-device-endpoints-from-bandwidth-list-whe.patch
(git-fixes CVE-2022-50470 bsc#1251202).
- commit a902bff
- fs: fix UAF/GPF bug in nilfs_mdt_destroy (CVE-2022-50367 bsc#1250277)
- commit d8f49e5
- cnic: Fix use-after-free bugs in cnic_delete_task
(CVE-2025-39945 bsc#1251230).
- iavf: Fix use-after-free in free_netdev (CVE-2023-53556
bsc#1251059).
- commit afb4745
- wifi: iwlwifi: mvm: don't trust firmware n_channels
(CVE-2023-53589 bsc#1251129).
- commit 988e8e2
- driver core: fix resource leak in device_add() (CVE-2023-53594
bsc#1251166).
- commit 5614ed9
- wifi: brcmfmac: ensure CLM version is null-terminated to
prevent stack-out-of-bounds (CVE-2023-53582 bsc#1251061).
- commit fad0717
- tracing: Add down_write(trace_event_sem) when adding trace event
(bsc#1248211 CVE-2025-38539).
- commit e8323f2
- ftrace: Also allocate and copy hash for reading of filter files
(bsc#1250032 CVE-2025-39813).
- commit fc74b08
- ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode
(bsc#1251197 CVE-2022-50485).
- commit e7befdc
- fs: writeback: fix use-after-free in __mark_inode_dirty()
(bsc#1250455 CVE-2025-39866).
- commit 71bbea8
- fs: Prevent file descriptor table allocations exceeding INT_MAX
(bsc#1249512 CVE-2025-39756).
- commit a3d8b0c
- ftrace: Fix potential warning in trace_printk_seq during
ftrace_dump (bsc#1250032 CVE-2025-39813).
- commit 4308207
- trace/fgraph: Fix the warning caused by missing unregister
notifier (bsc#1248211 CVE-2025-38539).
- commit 44bb2c8
- ipv6: Add lwtunnel encap size of all siblings in nexthop
calculation (CVE-2023-53477 bsc#1250840).
- commit 9c1503d
- drivers: base: Free devm resources when unregistering a device
(CVE-2023-53596 bsc#1251161).
- commit b016181
- media: v4l2-mem2mem: add lock to protect parameter num_rdy
(CVE-2023-53519 bsc#1250964).
- commit d68a51f
- ip_vti: fix potential slab-use-after-free in decode_session6
(CVE-2023-53559 bsc#1251052).
- commit 688b608
- Refresh
patches.suse/e1000e-fix-heap-overflow-in-e1000_set_eeprom.patch.
- commit 9531965
- ACPICA: Fix use-after-free in
acpi_ut_copy_ipackage_to_ipackage() (CVE-2022-50423
bsc#1250784).
- commit e5308a6
- scsi: lpfc: Fix buffer free/clear order in deferred receive path
(CVE-2025-39841 bsc#1250274).
- scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory
is allocated (CVE-2025-38700 bsc#1249182).
- scsi: bfa: Double-free fix (CVE-2025-38699 bsc#1249224).
- scsi: lpfc: Fix use-after-free KFENCE violation during sysfs
firmware write (CVE-2023-53282 bsc#1250311).
- scsi: target: iscsi: Fix a race condition between login_work
and the login thread (CVE-2022-50350 bsc#1250261).
- commit 204e345
- net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb
(CVE-2023-53548 bsc#1251066).
- blacklist.conf: CVE unknown at the time
- commit 7beb085
- drm/rockchip: lvds: fix PM usage counter unbalance in poweron (bsc#1250768 CVE-2022-50443)
- commit b56de15
- fs: dlm: fix invalid derefence of sb_lvbptr (bsc#1251741
CVE-2022-50516).
- commit 09e6897
- af_unix: Fix data-races around user->unix_inflight
(CVE-2023-53204 bsc#1249682).
- commit 77897d4
- media: si470x: Fix use-after-free in si470x_int_in_callback()
(CVE-2022-50542 bsc#1251330).
- commit 29b7473
- ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value (CVE-2022-50327 bsc#1249859)
- commit 18b9822
- scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport
structure (CVE-2025-38695 bsc#1249285).
- commit a538909
- cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()
(CVE-2022-50481 bsc#1251051).
- commit e12557d
- lwt: Fix return values of BPF xmit ops (bsc#1250074
CVE-2023-53338).
- commit 6dcc27e
- i2c: ismt: Fix an out-of-bounds bug in ismt_access() (CVE-2022-50394 bsc#1250107)
- commit 473df14
- wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes (CVE-2023-53185 bsc#1249820)
- commit ee941e7
- irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains (CVE-2023-53191 bsc#1249721)
- commit 3a22168
- ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume() (CVE-2023-53271 bsc#1249916)
- commit 0c5e1f7
- media: bdisp: Add missing check for create_workqueue (CVE-2023-53289 bsc#1249941)
- commit a94aab1
- crypto: seqiv - Handle EBUSY correctly (CVE-2023-53373 bsc#1250137)
- commit dd42b1d
- iommu/mediatek: Fix crash on isr after kexec() (CVE-2022-50236
bsc#1249702).
- commit 97b644f
- iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry() (CVE-2023-53476 bsc#1250839)
- commit 04895ff
- e1000e: fix heap overflow in e1000_set_eeprom (CVE-2025-39898
bsc#1250742).
- net: add vlan_get_protocol_and_depth() helper (CVE-2023-53433
bsc#1250164).
- commit 2836e8d
- drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init() (CVE-2022-50242 bsc#1249696)
- commit 2d1b74b
- igb: Do not bring the device up after non-fatal error
(CVE-2023-53148 bsc#1249842).
- commit d58ebba
- net: If sock is dead don't access sock's sk_wq in
sk_stream_wait_memory (CVE-2022-50409 bsc#1250392).
- commit d8d8ecd
- ppp: fix memory leak in pad_compress_skb (CVE-2025-39847
bsc#1250292).
- gve: prevent ethtool ops after shutdown (CVE-2025-38735
bsc#1249288).
- igb: Fix igb_down hung on surprise removal (CVE-2023-53148
bsc#1249842).
- qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable()
failure (CVE-2022-50288 bsc#1249802).
- igb: Do not free q_vector unless new one was allocated
(CVE-2022-50252 bsc#1249846).
- commit 0b4ef82
- Update
patches.suse/0001-media-dvb-usb-az6027-fix-null-ptr-deref-in-az6027_i2.patch
(bsc#1209291 CVE-2023-28328 CVE-2022-50272 bsc#1249808).
- Update
patches.suse/0001-ubi-ensure-that-VID-header-offset-VID-header-size-al.patch
(bsc#1210584 CVE-2023-53265 bsc#1249908).
- Update
patches.suse/0001-wifi-brcmfmac-slab-out-of-bounds-read-in-brcmf_get_a.patch
(bsc#1209287 CVE-2023-1380 CVE-2023-53213 bsc#1249918).
- Update
patches.suse/0012-md-Replace-snprintf-with-scnprintf.patch
(git-fixes bsc#1164051 CVE-2022-50299 bsc#1249734).
- Update patches.suse/NFS-Fix-an-Oops-in-nfs_d_automount.patch
(git-fixes CVE-2022-50385 bsc#1250131).
- Update
patches.suse/NFSD-Protect-against-send-buffer-overflow-in-NFSv2-R.patch
(bsc#1205128 CVE-2022-43945 bsc#1210124 CVE-2022-50410
bsc#1250187).
- Update
patches.suse/NFSD-Protect-against-send-buffer-overflow-in-NFSv2-Rdir.patch
(bsc#1205128 CVE-2022-43945 CVE-2022-50235 bsc#1249667).
- Update
patches.suse/PCI-ASPM-Disable-ASPM-on-MFD-function-removal-to-avo.patch
(git-fixes CVE-2023-53446 bsc#1250145).
- Update
patches.suse/blk-mq-fix-possible-memleak-when-register-hctx-failed-4b7a.patch
(git-fixes CVE-2022-50434 bsc#1250792).
- Update
patches.suse/bpf-make-sure-skb-len-0-when-redirecting-to-a-tunnel.patch
(CVE-2022-49975 bsc#1245196 CVE-2022-50253 bsc#1249912).
- Update
patches.suse/btrfs-fix-resolving-backrefs-for-inline-extent-follo.patch
(bsc#1213133 CVE-2022-50456 bsc#1250856).
- Update
patches.suse/chardev-fix-error-handling-in-cdev_device_add.patch
(git-fixes CVE-2022-50282 bsc#1249739).
- Update
patches.suse/cifs-Fix-memory-leak-when-build-ntlmssp-negotiate-blob-failed.patch
(bsc#1190317 CVE-2022-50372 bsc#1250052).
- Update
patches.suse/cifs-Fix-warning-and-UAF-when-destroy-the-MR-list.patch
(bsc#1190317 CVE-2023-53427 bsc#1250168).
- Update patches.suse/cifs-Fix-xid-leak-in-cifs_create-.patch
(bsc#1190317 CVE-2022-50351 bsc#1249925).
- Update patches.suse/cifs-Fix-xid-leak-in-cifs_flock-.patch
(bsc#1190317 CVE-2022-50460 bsc#1250879).
- Update
patches.suse/cifs-fix-DFS-traversal-oops-without-CONFIG_CIFS_DFS_UPCALL.patch
(bsc#1190317 CVE-2023-53246 bsc#1249867).
- Update
patches.suse/drm-vmwgfx-Validate-the-box-size-for-the-snooped-cur.patch
(bsc#1203332 CVE-2022-36280 CVE-2022-50440 bsc#1250853).
- Update
patches.suse/ext4-avoid-crash-when-inline-data-creation-follows-D.patch
(bsc#1206883 CVE-2022-50435 bsc#1250799).
- Update
patches.suse/ext4-avoid-deadlock-in-fs-reclaim-with-page-writebac.patch
(bsc#1213016 CVE-2023-53149 bsc#1249882).
- Update
patches.suse/ext4-fix-i_disksize-exceeding-i_size-problem-in-pari.patch
(bsc#1213015 CVE-2023-53270 bsc#1249872).
- Update
patches.suse/ext4-fix-null-ptr-deref-in-ext4_write_info.patch
(bsc#1206884 CVE-2022-50344 bsc#1250014).
- Update
patches.suse/ext4-init-quota-for-old.inode-in-ext4_rename.patch
(bsc#1207629 CVE-2022-50346 bsc#1250044).
- Update
patches.suse/firmware-dmi-sysfs-Fix-null-ptr-deref-in-dmi_sysfs_r.patch
(bsc#1238467 CVE-2023-53250 bsc#1249727).
- Update
patches.suse/genirq-ipi-Fix-NULL-pointer-deref-in-irq_data_get_af.patch
(git-fixes CVE-2023-53332 bsc#1249951).
- Update
patches.suse/ipv6-addrconf-fix-a-potential-refcount-underflow-for.patch
(git-fixes CVE-2023-53189 bsc#1249894).
- Update
patches.suse/jbd2-check-jh-b_transaction-before-removing-it-from-.patch
(bsc#1214953 CVE-2023-53526 bsc#1250928).
- Update
patches.suse/kernfs-fix-use-after-free-in-__kernfs_remove.patch
(git-fixes CVE-2022-50432 bsc#1250851).
- Update
patches.suse/kprobes-Fix-check-for-probe-enabled-in-kill_kprobe.patch
(git-fixes CVE-2022-50266 bsc#1249810).
- Update patches.suse/md-fix-a-crash-in-mempool_free-3410.patch
(git-fixes CVE-2022-50381 bsc#1250257).
- Update
patches.suse/md-raid10-check-slab-out-of-bounds-in-md_bitmap_get_-3018.patch
(git-fixes CVE-2023-53357 bsc#1249994).
- Update
patches.suse/md-raid10-fix-leak-of-r10bio-remaining-for-recovery-2620.patch
(git-fixes CVE-2023-53299 bsc#1249927).
- Update
patches.suse/md-raid10-fix-null-ptr-deref-of-mreplace-in-raid10_s-3481.patch
(git-fixes CVE-2023-53380 bsc#1250198).
- Update
patches.suse/md-raid10-fix-wrong-setting-of-max_corr_read_errors-f8b2.patch
(git-fixes CVE-2023-53313 bsc#1249911).
- Update
patches.suse/md-raid10-prevent-soft-lockup-while-flush-writes-0104.patch
(git-fixes CVE-2023-53151 bsc#1249865).
- Update
patches.suse/msft-hv-2841-scsi-storvsc-Fix-handling-of-virtual-Fibre-Channel-t.patch
(git-fixes CVE-2023-53245 bsc#1249641).
- Update
patches.suse/net-fec-Better-handle-pm_runtime_get-failing-in-.rem.patch
(git-fixes CVE-2023-53308 bsc#1250045).
- Update
patches.suse/netfilter-conntrack-dccp-copy-entire-header-to-stack.patch
(CVE-2023-39197 bsc#1216976 CVE-2023-53333 bsc#1249949).
- Update
patches.suse/netlink-avoid-infinite-retry-looping-in-netlink_unic.patch
(CVE-2025-38465 bsc#1247118 CVE-2025-38727 bsc#1249166).
- Update
patches.suse/nfsd-under-NFSv4.1-fix-double-svc_xprt_put-on-rpc_cr.patch
(git-fixes CVE-2022-50401 bsc#1250140).
- Update
patches.suse/ocfs2-fix-memory-leak-in-ocfs2_stack_glue_init.patch
(git-fixes CVE-2022-50289 bsc#1249981).
- Update
patches.suse/powerpc-Don-t-try-to-copy-PPR-for-task-with-NULL-pt_.patch
(bsc#1065729 CVE-2023-53326 bsc#1250071).
- Update
patches.suse/pstore-ram-Check-start-of-empty-przs-during-init.patch
(git-fixes CVE-2023-53331 bsc#1249950).
- Update
patches.suse/rbd-avoid-use-after-free-in-do_rbd_add-when-rbd_dev_-f7c4.patch
(git-fixes CVE-2023-53307 bsc#1250043).
- Update
patches.suse/sched-fair-Don-t-balance-task-to-its-current-running-CPU.patch
(git fixes (sched) CVE-2023-53215 bsc#1250397).
- Update
patches.suse/scsi-core-Fix-possible-memory-leak-if-device_add-fails.patch
(git-fixes CVE-2023-53174 bsc#1250024).
- Update
patches.suse/scsi-fcoe-Fix-transport-not-deattached-when-fcoe_if_init-fails.patch
(git-fixes CVE-2022-50414 bsc#1250183).
- Update
patches.suse/scsi-libsas-Fix-use-after-free-bug-in-smp_execute_task_sg.patch
(git-fixes CVE-2022-50422 bsc#1250774).
- Update patches.suse/scsi-mpt3sas-Fix-a-memory-leak.patch
(git-fixes CVE-2023-53512 bsc#1250915).
- Update
patches.suse/scsi-qla2xxx-Fix-potential-NULL-pointer-dereference.patch
(bsc#1213747 CVE-2023-53451 bsc#1250831).
- Update
patches.suse/scsi-qla2xxx-Pointer-may-be-dereferenced.patch
(bsc#1213747 CVE-2023-53150 bsc#1249853).
- Update
patches.suse/scsi-qla2xxx-Remove-unused-nvme_ls_waitq-wait-queue.patch
(bsc#1213747 CVE-2023-53280 bsc#1249938).
- Update
patches.suse/scsi-qla2xxx-Use-raw_smp_processor_id-instead-of-smp.patch
(git-fixes CVE-2023-53530 bsc#1250949).
- Update
patches.suse/scsi-qla2xxx-Wait-for-io-return-on-terminate-rport.patch
(bsc#1211960 CVE-2023-53322 bsc#1250323).
- Update
patches.suse/scsi-qla4xxx-Add-length-check-when-parsing-nlattrs.patch
(git-fixes CVE-2023-53456 bsc#1250765).
- Update
patches.suse/scsi-ses-Fix-slab-out-of-bounds-in-ses_intf_remove.patch
(git-fixes CVE-2023-53521 bsc#1250965).
- Update
patches.suse/scsi-snic-Fix-possible-memory-leak-if-device_add-fails.patch
(git-fixes CVE-2023-53436 bsc#1250156).
- Update
patches.suse/tpm-tpm_crb-Add-the-missed-acpi_put_table-to-fix-mem.patch
(bsc#1082555 CVE-2022-50389 bsc#1250121).
- Update
patches.suse/tracing-Fix-race-issue-between-cpu-buffer-write-and-swap.patch
(git-fixes CVE-2023-53368 bsc#1249979).
- Update
patches.suse/udf-Do-not-bother-merging-very-long-extents.patch
(bsc#1213040 CVE-2023-53506 bsc#1250963).
- Update
patches.suse/udf-Do-not-update-file-length-for-failed-writes-to-i.patch
(bsc#1213041 CVE-2023-53295 bsc#1250324).
- Update
patches.suse/udf-Fix-uninitialized-array-access-for-some-pathname.patch
(bsc#1214967 CVE-2023-53165 bsc#1250395).
- Update
patches.suse/vhost-vsock-Use-kvmalloc-kvfree-for-larger-packets.patch
(git-fixes CVE-2022-50271 bsc#1249740).
- Update
patches.suse/virtio_net-Fix-error-unwinding-of-XDP-initialization.patch
(git-fixes CVE-2023-53499 bsc#1250818).
- Update patches.suse/xen-gntdev-Prevent-leaking-grants.patch
(git-fixes CVE-2022-50257 bsc#1249743).
- Update
patches.suse/xfrm-add-NULL-check-in-xfrm_update_ae_params.patch
(bsc#1213666 CVE-2023-3772 CVE-2023-53147 bsc#1249880).
- commit f14b4f5
- i40e: Fix potential invalid access when MAC list is empty (CVE-2025-39853 bsc#1250275)
- commit 15849c1
- x86/tsc: Append the 'tsc=' description for the 'tsc=unstable'
boot parameter (git-fixes).
- Refresh
patches.suse/0004-x86-cpu-Add-a-tsx-cmdline-option-with-TSX-disabled-b.patch.
- commit fc36e71
- Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
(CVE-2025-39860 bsc#1250247).
- commit db1f312
- rpm/check-for-config-changes: ignore CONFIG_SCHED_PROXY_EXEC, too (bsc#1250946)
CONFIG_SCHED_PROXY_EXEC is set only when the debug is off, exclusive
to CONFIG_SCHED_CLASS_EXT.
- commit ac06fa9
- net: bridge: fix soft lockup in br_multicast_query_expired()
(CVE-2025-39773 bsc#1249504).
- net: bridge: mcast: add and enforce startup query interval
minimum (CVE-2025-39773 bsc1249504).
- net: bridge: mcast: add and enforce query interval minimum
(CVE-2025-39773 bsc1249504).
- commit 86febde
- HID: asus: fix UAF via HID_CLAIMED_INPUT validation
(CVE-2025-39824 bsc#1250007).
- commit 74f7410
- ip6mr: Fix skb_under_panic in ip6mr_cache_report()
(CVE-2023-53365 bsc#1249988).
- commit 31b9909
- dmaengine: ti: edma: Fix memory allocation size for
queue_priority_map (CVE-2025-39869 bsc#1250406).
- commit 0c7b875
- netfilter: ctnetlink: remove refcounting in expectation dumpers
(CVE-2025-39764 bsc#1249513).
- commit 21919f3
- net/sched: Fix backlog accounting in qdisc_dequeue_internal
(CVE-2025-39677 bsc#1249300).
- commit 019e014
- cifs: prevent NULL pointer dereference in UTF16 conversion
(bsc#1250365, CVE-2025-39838).
- commit a653056
- l2tp: remove unused list_head member in l2tp_tunnel (git-fixes).
- commit a146724
- Refresh
patches.suse/l2tp-prevent-lockdep-issue-in-l2tp_tunnel_register.patch.
Move the call to release_sock() to match upstream. This will make
future backports easier.
- commit 7c5477e
- Bluetooth: eir: Fix using strlen with
hdev->{dev_name,short_name} (CVE-2022-50233 bsc#1246968).
- commit 7861eb7
- Update
patches.suse/ACPICA-Fix-error-code-path-in-acpi_ds_call_control_method.patch
(bsc#1250393 CVE-2022-50411).
Fix wrongly C&Ped bug and CVE number.
- commit c1344a1
- ocfs2: fix recursive semaphore deadlock in fiemap call
(bsc#1250407 CVE-2025-39885).
- commit fa96337
- mm/smaps: fix race between smaps_hugetlb_range and migration
(CVE-2025-39754 bsc#1249524).
- commit c2c05c6
- media: cx88: Fix a null-ptr-deref bug in buffer_prepare()
(CVE-2022-50359 bsc#1250269).
- commit 680e9a1
- mISDN: hfcpci: Fix warning when deleting uninitialized timer
(CVE-2025-39833 bsc#1250028).
- commit 44dd6de
- net: ena: fix shift-out-of-bounds in exponential backoff (CVE-2023-53272 bsc#1249917)
- commit 79f3645
- Refresh
patches.suse/btrfs-fix-deadlock-when-aborting-transaction-during-.patch.
- Refresh
patches.suse/btrfs-prevent-ioctls-from-interfering-with-a-swap-file.patch.
- commit df48fdf
- wifi: brcmfmac: fix use-after-free when rescheduling
brcmf_btcoex_info work (CVE-2025-39863 bsc#1250281).
- commit b50d5fe
- serial: 8250: Fix oops for port->pm on uart_change_pm()
(CVE-2023-53176 bsc#1249991).
- commit ef178fc
- Bluetooth: L2CAP: Fix user-after-free (CVE-2022-50386
bsc#1250301).
- Refresh
patches.suse/Bluetooth-L2CAP-Fix-corrupted-list-in-hci_chan_del.patch.
- commit ef8e23b
- mm: zswap: fix missing folio cleanup in writeback race path
(CVE-2023-53178 bsc#1249827 git-fix).
- commit 556f4d6
- mm: fix zswap writeback race condition (CVE-2023-53178
bsc#1249827).
- commit 58cd2c5
- Bluetooth: hci_sysfs: Fix attempting to call device_add multiple
times (CVE-2022-50419 bsc#1250394).
- commit b4e8638
- wifi: brcmfmac: fix use-after-free bug in
brcmf_netdev_start_xmit() (CVE-2022-50408 bsc#1250391).
- commit d1d8e28
- ALSA: hda: Fix Oops by 9.1 surround channel names
(CVE-2023-53400 bsc#1250328).
- commit ba820fb
- wifi: mac80211_hwsim: drop short frames (CVE-2023-53321
bsc#1250313).
- commit 6ddc75a
- tee: fix NULL pointer dereference in tee_shm_put (CVE-2025-39865
bsc#1250294).
- commit f721184
- serial: 8250: Reinit port->pm on port specific driver unbind
(CVE-2023-53176 bsc#1249991).
- tty: serial: fsl_lpuart: disable dma rx/tx use flags in
lpuart_dma_shutdown (CVE-2022-50375 bsc#1250132).
- Refresh
patches.suse/tty-serial-fsl_lpuart-fix-race-on-RX-DMA-shutdown.patch.
- drivers: serial: jsm: fix some leaks in probe (CVE-2022-50312
bsc#1249716).
- commit 1aca549
- wifi: ath9k: verify the expected usb_endpoints are present
(CVE-2022-50297 bsc#1250250).
- commit 6950b3a
- wifi: iwl4965: Add missing check for
create_singlethread_workqueue() (CVE-2023-53302 bsc#1249958).
- commit 8f88848
- nfc: fix memory leak of se_io context in nfc_genl_se_io
(CVE-2023-53298 bsc#1249944).
- Refresh
patches.suse/nfc-change-order-inside-nfc_se_io-error-path.patch.
- commit d32133b
- x86/MCE: Always save CS register on AMD Zen IF Poison errors
(CVE-2023-53438 bsc#1250180).
- commit bf84e9b
- wifi: mwifiex: avoid possible NULL skb pointer dereference
(CVE-2023-53384 bsc#1250127).
- commit d34c18b
- ALSA: usb-audio: Fix size validation in convert_chmap_v3()
(CVE-2025-39757 bsc#1249515).
- commit 0ab86d7
- HID: hid-ntrig: fix unable to handle page fault in
ntrig_report_version() (CVE-2025-39808 bsc#1250088).
- commit 5536678
- Bluetooth: L2CAP: Fix use-after-free (CVE-2023-53305
bsc#1250049).
- Refresh
patches.suse/Bluetooth-L2CAP-Fix-corrupted-list-in-hci_chan_del.patch.
- commit ac84db6
- wifi: iwl3945: Add missing check for
create_singlethread_workqueue (CVE-2023-53277 bsc#1249936).
- commit 4da361d
- soc: qcom: mdt_loader: Deal with zero e_shentsize
(CVE-2025-39787 bsc#1249545).
- soc: qcom: mdt_loader: Fix error return values in
mdt_header_valid() (CVE-2025-39787 bsc#1249545).
- commit 529120f
- ALSA: usb-audio: Validate UAC3 cluster segment descriptors
(CVE-2025-39757 bsc#1249515).
- soc: qcom: mdt_loader: Ensure we don't read past the ELF header
(CVE-2025-39787 bsc#1249545).
- commit 5d06f31
- btrfs: abort transaction on unexpected eb generation at
btrfs_copy_root() (bsc#1250177 CVE-2025-39800).
- Refresh
patches.suse/0001-btrfs-Introduce-support-for-FSID-change-without-meta.patch.
- Refresh
patches.suse/0002-btrfs-Remove-fsid-metadata_fsid-fields-from-btrfs_in.patch.
- commit ebb9819
- kernel-source.spec: Depend on python3-base for build
Both kernel-binary and kernel-docs already have this dependency.
Adding it to kernel-source makes it possible to use python in shared
build scripts.
- commit 72fdedd
- kernel-source: Do not list mkspec and its inputs as sources
(bsc#1250522).
This excludes the files from the src.rpm. The next step is to remove
these files in tar-up so that they do not get uploaded to OBS either.
As there is only one version of tar-up these files need to be removed
from all kernels.
- commit e72b8a2
- bpf: cpumap: Fix memory leak in cpu_map_update_elem (bsc#1250150
CVE-2023-53441).
- commit 77b4844
- drivers/md/md-bitmap: check the return value of
md_bitmap_get_counter() (CVE-2022-50402, bsc#1250363).
- commit b998cb4
- ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer (bsc#1250358
CVE-2023-53395).
- commit 16cf2b4
- ACPICA: Fix error code path in acpi_ds_call_control_method()
(bsc#1249615 CVE-2025-39763).
- commit 00cd9ae
- rpm: Link arch-symbols script from scripts directory.
- commit 90b2abb
- skbuff: Account for tail adjustment during pull operations
(CVE-2022-50365 bsc#1250084).
- commit 2c0b58b
- btrfs: fix deadlock when aborting transaction during relocation
with scrub (bsc#1250018 CVE-2023-53348).
- commit 6970fda
- use uniform permission checks for all mount propagation changes
(git-fixes).
- commit 5972133
- net/tunnel: wait until all sk_user_data reader finish before
releasing the sock (CVE-2022-50405 bsc#1250155).
- commit aea82ac
- rpm: Link guards script from scripts directory.
- commit e19a893
- usb: core: config: Prevent OOB read in SS endpoint companion
parsing (CVE-2025-39760 bsc#1249598).
- commit ee5b3a5
- can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write
(CVE-2023-53344 bsc#1250023).
- net: sched: fix memory leak in tcindex_set_parms (CVE-2022-50396
bsc#1250104).
- net: hns: fix possible memory leak in hnae_ae_register()
(CVE-2022-50352 bsc#1249922).
- commit 10ff501
- drm/client: Fix memory leak in drm_client_modeset_probe (bsc#1250058 CVE-2023-53288)
- commit d2583cc
- modpost: fix off by one in is_executable_section() (bsc#1250125
CVE-2023-53397).
- commit 1e88ffb
- dma-buf: add dma_fence_get_stub (bsc#1249779)
- commit af3d574
- drm/amdgpu: install stub fence into potential unused fence pointers (bsc#1249779 CVE-2023-53248)
- commit 2f24c24
- Refresh patches.kabi/blkg_policy_data-fix-kabi.patch.
- Refresh
patches.kabi/xsk-Fix-race-condition-in-AF_XDP-generic-RX-path.patch.
- commit aee218b
- fixup patches.suse/ext4-fix-WARNING-in-mb_find_extent.patch
- commit bc062c7
- RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device (CVE-2023-53393 bsc#1250114)
- commit 3367be7
- RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish() (CVE-2023-53335 bsc#1250072)
- commit de7e5a8
- drm/radeon: Fix integer overflow in radeon_cs_parser_init
(CVE-2023-53309 bsc#1250055).
- commit 0fc616d
- Refresh patches.kabi/blkg_policy_data-fix-kabi.patch.
- commit 5d9cd59
- Update config files. (bsc#1249186)
Enable where we define KABI refs + rely on Kconfig deps.
- commit a2cab75
- Refresh patches.kabi/blkg_policy_data-fix-kabi.patch.
- Refresh
patches.kabi/xsk-Fix-race-condition-in-AF_XDP-generic-RX-path.patch.
Semiautomatic
git grep -l BUILD_BUG_ON patches.kabi/ | xargs sed -i '/^+/s/\<BUILD_BUG_ON\>/suse_kabi_static_assert/'
plus manual drop of guard in blkg_policy_data-fix-kabi.patch.
- commit 7689a50
- build_bug.h: add wrapper for _Static_assert (bsc#1249186).
- commit 55004e9
- iomap: iomap: fix memory corruption when recording errors
during writeback (bsc#1250165 CVE-2022-50406).
- commit 5a4f1a7
- ext4: fix WARNING in mb_find_extent (bsc#1250081
CVE-2023-53317).
- commit 85276b3
- jbd2: prevent softlockup in jbd2_log_do_checkpoint()
(bsc#1249526 CVE-2025-39782).
- commit 3659634
- ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
(bsc#1249258 CVE-2025-38701).
- commit a95c36d
- fs/buffer: fix use-after-free when call bh_read() helper
(bsc#1249374 CVE-2025-39691).
- commit f608a73
- kcm: annotate data-races around kcm->rx_wait (CVE-2022-50265
bsc#1249744).
- kcm: annotate data-races around kcm->rx_psock (CVE-2022-50291
bsc#1249798).
- commit aaba982
- hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
(bsc#1249194 CVE-2025-38712).
- commit 521eb34
- hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
(bsc#1249200 CVE-2025-38713).
- commit 91e012f
- wifi: brcmfmac: Fix potential stack-out-of-bounds in
brcmf_c_preinit_dcmds() (CVE-2022-50258 bsc#1249947).
- commit 5e60cf0
- drivers: base: cacheinfo: Fix shared_cpu_map changes in event
of CPU hotplug (CVE-2023-53254 bsc#1249871).
- commit d73f053
- cacheinfo: Fix shared_cpu_map to handle shared caches at
different levels (CVE-2023-53254 bsc#1249871).
- commit b2d75ed
- wifi: mwifiex: Fix oob check condition in
mwifiex_process_rx_packet (CVE-2023-53226 bsc#1249658).
- wifi: mwifiex: Fix missed return in oob checks failed path
(CVE-2023-53226 bsc#1249658).
- wifi: cfg80211: Partial revert "wifi: cfg80211: Fix use after
free for wext" (CVE-2023-53153 bsc#1249877).
- commit 01aaa87
- wifi: mwifiex: Fix OOB and integer underflow when rx packets
(CVE-2023-53226 bsc#1249658).
- wifi: cfg80211: Fix use after free for wext (CVE-2023-53153
bsc#1249877).
- wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream()
fails (CVE-2023-53199 bsc#1249683).
- commit f427ccc
- crypto: cavium - prevent integer overflow loading firmware
(CVE-2022-50330 bsc#1249700).
- commit 489e575
- crypto: cavium - add release_firmware to all return case
(CVE-2022-50330 bsc#1249700).
- commit 372d22d
- misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()
(CVE-2022-50349 bsc#1249920).
- commit 658f5fe
- wifi: brcmfmac: fix potential memory leak in
brcmf_netdev_start_xmit() (CVE-2022-50321 bsc#1249706).
- commit d3baaae
- cxl: Fix refcount leak in cxl_calc_capp_routing (CVE-2022-50311
bsc#1249720).
- commit 70f8a07
- mm: export bdi_unregister (CVE-2022-50304 bsc#1249725).
- commit 9420929
- mtd: core: fix possible resource leak in init_mtd()
(CVE-2022-50304 bsc#1249725).
- commit 191b4a8
- mm,hugetlb: take hugetlb_lock before decrementing
h->resv_huge_pages (CVE-2022-50285 bsc#1249803).
- commit 53c2d88
- RDMA/bnxt_re: wraparound mbox producer index (CVE-2023-53201 bsc#1249687)
- commit 4aab7ab
- wifi: libertas: fix memory leak in lbs_init_adapter()
(CVE-2022-50294 bsc#1249799).
- cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()
(CVE-2022-50244 bsc#1249647).
- PNP: fix name memory leak in pnp_alloc_dev() (CVE-2022-50278
bsc#1249715).
- commit c3e3de7
- drm/amd/pm: fix null pointer access (CVE-2025-38705
bsc#1249334).
- commit 6b431f7
- fbdev: fix potential buffer overflow in
do_register_framebuffer() (CVE-2025-38702 bsc#1249254).
- commit 4004fc6
- drm/amdkfd: Destroy KFD debugfs after destroy KFD wq
(CVE-2025-39706 bsc#1249413).
- commit 83af3ba
- Refresh
patches.suse/Bluetooth-Replace-BT_DBG-with-bt_dev_dbg-for-managem.patch.
- commit c6ff1e0
- ALSA: hda/ca0132: Fix buffer overflow in add_tuning_control
(CVE-2025-39751 bsc#1249538).
- commit 8a44263
- kABI fix after x86/vmscape: Add conditional IBPB mitigation
(bsc#1247483 CVE-2025-40300).
- commit 0df5e36
- drm/amd/display: fix a Null pointer dereference vulnerability (bsc#1249295 CVE-2025-39705)
- commit 478e53d
- Bluetooth: hci_core: Fix calling mgmt_device_connected
(git-fixes).
- commit bd515e0
- ALSA: usb-audio: Validate UAC3 power domain descriptors, too
(CVE-2025-38729 bsc#1249164).
- commit 8b412cb
- pptp: fix pptp_xmit() error path (git-fixes).
- pptp: ensure minimal skb length in pptp_xmit() (CVE-2025-38574
bsc#1248365).
- can: netlink: can_changelink(): fix NULL pointer deref of
struct can_priv::do_set_mode (CVE-2025-38665 bsc#1248648).
- tls: separate no-async decryption request handling from async
(CVE-2024-58240 bsc#1248847).
- commit cb8a609
- Limit patch filenames to 100 characters (bsc#1249604).
- commit e94c0ca
- smb: client: fix use-after-free in cifs_oplock_break
(bsc#1248199, CVE-2025-38527).
- commit e4dac9c
- tipc: improve function tipc_wait_for_cond() (bsc#1249037).
- commit 66b60a2
- PCI: Fix use-after-free of slot->bus on hot remove
(CVE-2024-53194 bsc#1235459).
- commit 8ed6518
- kernel-subpackage-build: Decompress ghost file when compressed version exists (bsc#1249346)
- commit 40606b5
- powerpc/eeh: Export eeh_unfreeze_pe() (CVE-2025-38623
bsc#1248610).
- commit e1ab8da
- pci/hotplug/pnv-php: Wrap warnings in macro (CVE-2025-38623
bsc#1248610).
- commit fcff164
- PCI: pnv_php: Fix surprise plug detection and recovery
(CVE-2025-38623 bsc#1248610).
- commit 77a6e44
- PCI: pnv_php: Clean up allocated IRQs on unplug (CVE-2025-38624
bsc#1248617).
- commit f20bd36
- netfilter: xt_nfacct: don't assume acct name is null-terminated (CVE-2025-38639 bsc#1248674)
- commit 85e9df6
- s390/ism: fix concurrency management in ism_cmd() (git-fixes
bsc#1249266 CVE-2025-39726).
- commit 4cdfb37
- fbdev: Fix vmalloc out-of-bounds write in fast_imageblit (bsc#1249220 CVE-2025-38685)
- commit d40c5ad
- pinmux: fix race causing mux_owner NULL with active mux_usecount
(CVE-2025-38632 bsc#1248669).
- commit 417d30f
- smb: client: fix use-after-free in crypt_message when using
async crypto (bsc#1247239, CVE-2025-38488).
- commit f68b209
- wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()
(CVE-2025-38602 bsc#1248341).
- commit 26c0123
- iwlwifi: Add missing check for alloc_ordered_workqueue
(CVE-2025-38602 bsc#1248341).
- commit 1f095f0
- wifi: rtl818x: Kill URBs before clearing tx status queue (CVE-2025-38604 bsc#1248333)
- commit 3582a16
- ipv6: reject malicious packets in ipv6_gso_segment()
(CVE-2025-38572 bsc#1248399).
- net/sched: Restrict conditions for adding duplicating netems
to qdisc tree (CVE-2025-38553 bsc#1248255).
- commit edb7431
- rpm: Configure KABI checkingness macro (bsc#1249186)
The value of the config should match presence of KABI reference data. If
it mismatches:
- !CONFIG & reference -> this is bug, immediate fail
- CONFIG & no reference -> OK temporarily, must be resolved eventually
- commit 23c1536
- Kconfig.suse: Add KABI checkiness macro (config) (bsc#1249186)
The motivation: there are patches.kabi/ patches that restore KABI and
they check validity of the approach with static_assert()s to prevent
accidental KABI breakage.
These asserts are invoked on each arch-flavor and they may signal false
negatives -- that is KABI restoration patch could break KABI but the
given arch-flavor defines no KABI.
The intended use is to disable the compile time checks in patches.kabi/
(but not to be confused with __GENKSYMS__ that affects how reference is
calculated).
The name is chosen so that it mimics HAVE_* macros that are not
configured manually (but is selected by an arch). In our case it's
(un)selected by build script depending on whether KABI reference is
defined for given arch-flavor and whether check is really requested by
the user. Default value is 'n' so that people building merely via
Makefile (not RPM with KABI checking) obtain consistent config.
- commit 75ce338
- usb: xhci: Apply the link chain quirk on NEC isoc endpoints
(CVE-2025-22022 bsc#1241292).
- commit b35c518
- usb: xhci: move link chain bit quirk checks into one helper
function (CVE-2025-22022 bsc#1241292).
- commit e8f6e8b
- drm/framebuffer: Fix object locking in destroy function (bsc#1248130)
Fix the locking in drm_gem_fb_destroy(). This is an bug in the backport
of commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on
GEM handles") for bsc#1247255.
- commit 8b690c9
- HID: core: Harden s32ton() against conversion to 0 bits (CVE-2025-38556 bsc#1248296)
- commit efa9b29
- Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() (CVE-2025-38473 bsc#1247289)
- commit 3bda5d9
- bus: fsl-mc: fix double-free on mc_dev (CVE-2025-38313 bsc#1246342)
- commit cfe0da6
- bcache: fix NULL pointer in cache_set_flush() (CVE-2025-38263 bsc#1246248)
- commit 0207ad5
- wifi: mac80211: reject TDLS operations when station is not
associated (CVE-2025-38644 bsc#1248748).
- commit 38baafe
- vsock: Do not allow binding to VMADDR_PORT_ANY (bsc#1248511
CVE-2025-38618).
- commit 7301855
- USB: gadget: Fix obscure lockdep violation for udc_mutex
(CVE-2022-49980 bsc#1245110).
- commit e73f583
- usb: gadget: Fix use-after-free bug by not setting
udc->dev.driver (CVE-2022-49980 bsc#1245110).
- commit 7b2e080
- usb: gadget: udc: core: Use pr_fmt() to prefix messages
(CVE-2022-49980 bsc#1245110).
- commit 342cb6b
- usb: gadget: core: do not try to disconnect gadget if it is
not connected (CVE-2022-49980 bsc#1245110).
- commit 6ce9821
- USB: gadget core: Issue ->disconnect() callback from
usb_gadget_disconnect() (CVE-2022-49980 bsc#1245110).
- commit e372dab
- usb: gadget: udc: Use scnprintf() instead of snprintf()
(CVE-2022-49980 bsc#1245110).
- commit 01ff878
- usb: gadget: udc: remove duplicate & operation (CVE-2022-49980
bsc#1245110).
- commit 6258328
- usb: gadget: remove redundant self assignment (CVE-2022-49980
bsc#1245110).
- commit aa82e52
- Update patches.suse/perf-core-Exit-early-on-perf_mmap-fail.patch
(CVE-2025-38563 bsc#1248306 dependency CVE-2025-38565
bsc#1248377).
- commit d0832f2
- thunderbolt: Do not double dequeue a configuration request (CVE-2025-38174 bsc#1245781)
- commit 34371af
- fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var (CVE-2025-38214 bsc#1246042)
- commit 4cdcf0a
- tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer (CVE-2025-38184 bsc#1245956)
- commit f59dd51
- gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO (CVE-2025-38122 bsc#1245746)
- commit c710bdd
- net: usb: aqc111: debug info before sanitation (bsc#1245744)
- commit 3ab10bb
- net: usb: aqc111: fix error handling of usbnet read calls (CVE-2025-38153 bsc#1245744)
- commit 0a0b0b6
- VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify (CVE-2025-38102 bsc#1245669)
- commit 104e403
- kernel-binary: Another installation ordering fix (bsc#1241353).
- commit fe14ab5
- Fix backport of the patch:
patches.suse/ext4-fix-race-when-reusing-xattr-blocks.patch (bsc#1247929)
- commit 2389678
- USB: gadget: Fix use-after-free Read in usb_udc_uevent()
(CVE-2022-49980 bsc#1245110).
- commit 5e1438b
- perf/core: Prevent VMA split of buffer mappings (CVE-2025-38563
bsc#1248306).
- commit 8cbbc54
- perf/core: Exit early on perf_mmap() fail (CVE-2025-38563
bsc#1248306 dependency).
- commit 45bf71a
- usb: net: sierra: check for no status endpoint (CVE-2025-38474
bsc#1247311).
- commit 9d6b398
- perf/core: Don't leak AUX buffer refcount on allocation failure
(CVE-2025-38563 bsc#1248306 dependency).
- commit 6e78f38
- atm: clip: Fix memory leak of struct clip_vcc (CVE-2025-38546
bsc#1248223).
- commit 9623eb0
- hid: hide cleanup of hid_descriptor (CVE-2025-38103
bsc#1245663).
- commit 13489bf
- HID: usbhid: Eliminate recurrent out-of-bounds bug in
usbhid_parse() (CVE-2025-38103 bsc#1245663).
- commit de56614
- wifi: zd1211rw: Fix potential NULL pointer dereference in
zd_mac_tx_to_dev() (CVE-2025-38513 bsc#1248179).
- commit 5d08711
- drm/sched: Increment job count before swapping tail spsc queue
(CVE-2025-38515 bsc#1248212).
- commit c4cd790
- bluetooth put new member for hci_dev at end (CVE-2025-38117
bsc#1245695).
- commit 0a0a7e2
- bluetooth: hide change to struct mgmt_pending_cmd
(CVE-2025-38117 bsc#1245695).
- commit be95d10
- build_bug.h: Add KABI assert (bsc#1249186).
- commit 9a1fb64
- wifi: prevent A-MSDU attacks in mesh networks (CVE-2025-38512
bsc#1248178).
- commit b3fbfce
- crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY (bsc#1225527)
- commit 696796d
- clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns (CVE-2025-38499 bsc#1247976)
- commit 853d04a
- net/packet: fix a race in packet_set_ring() and
packet_notifier() (CVE-2025-38617 bsc#1248621).
- commit b606d75
- atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister() (CVE-2025-38245 bsc#1246193)
- commit b752c31
- atm: Revert atm_account_tx() if copy_from_iter_full() fails (CVE-2025-38190 bsc#1245973)
- commit 3bb91d5
- atm: atmtcp: Free invalid length skb in atmtcp_c_send() (CVE-2025-38185 bsc#1246012)
- commit eb7640e
- x86/vmscape: Warn when STIBP is disabled with SMT (bsc#1247483 CVE-2025-40300).
- commit c527311
- x86/bugs: Move cpu_bugs_smt_update() down (bsc#1247483 CVE-2025-40300).
- commit 42c2e27
- x86/vmscape: Enable the mitigation (bsc#1247483 CVE-2025-40300).
- Update config files.
- Update patches.suse/powerpc-64s-flush-L1D-on-kernel-entry.patch
- Update patches.suse/powerpc-64s-flush-L1D-after-user-accesses.patch
- commit 8655743
- x86/vmscape: Add conditional IBPB mitigation (bsc#1247483 CVE-2025-40300).
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit c1e08fc
- x86/vmscape: Enumerate VMSCAPE bug (bsc#1247483 CVE-2025-40300).
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 12b0c37
- crypto: marvell/cesa - Handle zero-length skcipher requests (CVE-2025-38173 bsc#1245769)
- commit 202473d
- tee: fix compiler warning in tee_shm_register() (CVE-2022-50080 bsc#1244972)
- commit 22a7c7b
- tee: add overflow check in register_shm_helper() (CVE-2022-50080 bsc#1244972)
- commit a02103f
- KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0 (CVE-2022-50228 bsc#1244854)
- commit ac7e443
- drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() (CVE-2022-50185 bsc#1244887)
- commit 50be8a6
- ALSA: bcd2000: Fix a UAF bug on the error path of probing (CVE-2022-50229 bsc#1244856)
- commit f2b2849
- regulator: of: Fix refcount leak bug in of_get_regulation_constraints() (CVE-2022-50191 bsc#1244899)
- commit de6ac5a
- mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch (CVE-2022-50141 bsc#1244794)
- commit 6834f5d
- net: atlantic: fix aq_vec index out of range error (CVE-2022-50066 bsc#1244985).
- commit 6c25c9e
- Update config files. Disable N_GSM (jsc#PED-8240, bsc#1244824, CVE-2022-50116)
- commit e07a3f6
- tipc: Fix use-after-free in tipc_conn_close() (CVE-2025-38464
bsc#1247112).
- commit 9f4aa7a
- Documentation/hw-vuln: Add VMSCAPE documentation (bsc#1247483 CVE-2025-40300).
- commit 147b470
- xfrm: fix refcount leak in __xfrm_policy_check() (CVE-2022-50007 bsc#1245016)
- commit 8245963
- wifi: libertas: Fix possible refcount leak in if_usb_probe() (CVE-2022-50162 bsc#1244773)
- commit 67efefc
- HID: hidraw: fix a problem of memory leak in hidraw_release() (bsc#1245072)
- commit 990e001
- HID: hidraw: fix memory leak in hidraw_release() (CVE-2022-49981 bsc#1245072)
- commit ffa8f52
- scsi: target: iscsi: Fix timeout on deleted connection (CVE-2025-38075 bsc#1244734)
- commit c2e8d4f
- bpf: Fix a data-race around bpf_jit_limit (CVE-2022-49967 bsc#1244964)
- commit b2d2477
- crypto: pcrypt - Fix hungtask for PADATA_RESET (CVE-2023-52813 bsc#1225527)
- commit b063c0a
- RDMA/rxe: Fix error unwind in rxe_create_qp() (CVE-2022-50127 bsc#1244815)
- commit bd0b886
- RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() (CVE-2022-50138 bsc#1244797)
- commit 585ba4c
- Refresh patches.suse/x86-alternative-Merge-include-files.patch.
- commit 61adacf
- drm/framebuffer: Acquire internal references on GEM handles (bsc#1247255)
- commit 13075c4
- Move pesign-obs-integration requirement from kernel-syms to kernel devel
subpackage (bsc#1248108).
- commit e707e41
- drm/gem: Acquire references on GEM handles for framebuffers (bsc#1247255 CVE-2025-38449)
- commit 4e06401
- KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses
(bsc#1242782, CVE-2025-23141).
- commit 9f573f0
- netlink: avoid infinite retry looping in netlink_unicast()
(CVE-2025-38465 bsc#1247118).
- commit 0acd3ff
- posix-cpu-timers: fix race between handle_posix_cpu_timers()
and posix_cpu_timer_del() (bsc#1246911 CVE-2025-38352).
- blacklist.conf: CVE-2022-50159
- commit 0e930ec
- kABI fix for net: vlan: fix VLAN 0 refcount imbalance of
toggling (CVE-2025-38470 bsc#1247288).
- net: vlan: fix VLAN 0 refcount imbalance of toggling filtering
during runtime (CVE-2025-38470 bsc#1247288).
- net/sched: Abort __tc_modify_qdisc if parent class does not
exist (CVE-2025-38457 bsc#1247098).
- atm: clip: Fix potential null-ptr-deref in to_atmarpd()
(CVE-2025-38460 bsc#1247143).
- net: sched: simplify the qdisc_leaf code (CVE-2025-38457
bsc#1247098).
- commit bc4b1c9
- x86/its: Align RETs in BHB clear sequence to avoid thunking (bsc#1242006 CVE-2024-28956).
- commit 9e72e87
- x86/its: Add "vmexit" option to skip mitigation on some CPUs (bsc#1242006 CVE-2024-28956).
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 7095d7d
- x86/its: Enable Indirect Target Selection mitigation (bsc#1242006 CVE-2024-28956).
- commit 06978e9
- x86/its: Add support for ITS-safe return thunk (bsc#1242006 CVE-2024-28956).
- commit ed80f34
- x86/its: Add support for ITS-safe indirect thunk (bsc#1242006 CVE-2024-28956).
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 847f2c0
- do_change_type(): refuse to operate on unmounted/not ours mounts (CVE-2025-38498 bsc#1247374)
- commit fc35a30
- af_packet: Don't send zero-byte data in packet_sendmsg_spkt()
(CVE-2022-49975 bsc#1245196).
- bpf: Move skb->len == 0 checks into __bpf_redirect
(CVE-2022-49975 bsc#1245196).
- bpf: make sure skb->len != 0 when redirecting to a tunneling
device (CVE-2022-49975 bsc#1245196).
- net/ieee802154: don't warn zero-sized raw_sendmsg()
(CVE-2022-49975 bsc#1245196).
- net/af_packet: check len when min_header_len equals to 0
(CVE-2022-49975 bsc#1245196).
- bpf: Don't redirect packets with invalid pkt_len (CVE-2022-49975
bsc#1245196).
- bpf: in __bpf_redirect_no_mac pull mac only if present
(CVE-2022-49975 bsc#1245196).
- commit bde4efa
- ACPICA: Refuse to evaluate a method if arguments are missing
(CVE-2025-38386 bsc#1247138).
- commit 2984cfb
- x86/asm: Provide ALTERNATIVE_3 (git-fixes).
- commit f737462
- nfsd: nfsd4_spo_must_allow() must check this is a v4 compound
request (bsc#1247160 CVE-2025-38430).
- commit 53125b5
- linkage: Introduce new macros for assembler symbols (git-fixes).
- commit e08683f
- x86: Simplify retpoline declaration (git-fixes).
- Refresh patches.suse/x86-Add-magic-AMD-return-thunk.patch.
- Refresh
patches.suse/x86-cpu-Fix-up-srso_safe_ret-and-__x86_return_thunk.patch.
- Refresh
patches.suse/x86-cpu-Rename-srso_-.-_alias-to-srso_alias_-1.patch.
- Refresh patches.suse/x86-retpoline-Use-mfunction-return.patch.
- Refresh
patches.suse/x86-retpoline-kprobes-Fix-position-of-thunk-sections-with-.patch.
- Refresh
patches.suse/x86-srso-add-a-speculative-ras-overflow-mitigation.patch.
- commit 8b2413e
- netlink: make sure we allow at least one dump skb
(CVE-2025-38465 bsc#1247118).
- netlink: Fix rmem check in netlink_broadcast_deliver()
(CVE-2025-38465 bsc#1247118).
- netlink: Fix wraparounds of sk->sk_rmem_alloc (CVE-2025-38465
bsc#1247118).
- commit 0e7befb
- l2tp: convert l2tp_tunnel_list to idr (CVE-2023-53020 bsc#1240224).
Fix locking imbalance introduced by earlier backport.
(See bsc#1240224 comment 10.)
- Refresh
patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch.
- Refresh
patches.suse/l2tp-prevent-lockdep-issue-in-l2tp_tunnel_register.patch.
- commit e975b9c
- l2ip: fix possible use-after-free (CVE-2023-53020 bsc#1240224).
A prerequisity for a locking issue fix.
- commit c99f095
- x86/alternatives: Add an ALTERNATIVE_3() macro (git-fixes).
- commit 7cd3769
- x86/alternatives: Print containing function (git-fixes).
- commit 195541d
- x86/alternatives: Add macro comments (git-fixes).
- commit efb228e
- x86/alternative: Merge include files (git-fixes).
- Refresh
patches.suse/x86-lib-atomic64_386_32-rename-things.patch.
- Refresh
patches.suse/x86-srso-add-a-speculative-ras-overflow-mitigation.patch.
- commit d6a4cdb
- fs: prevent out-of-bounds array speculation when closing a
file descriptor (CVE-2023-53117 bsc#1242780).
- commit f9988ba
- update patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch
Fix locking imbalance in the backport, see bsc#1240224 comment 10.
- commit 5e477f0
- net/sched: sch_qfq: Avoid triggering might_sleep in atomic
context in qfq_delete_class (CVE-2025-38477 bsc#1247314).
- net/sched: Return NULL when htb_lookup_leaf encounters an
empty rbtree (CVE-2025-38468 bsc#1247437).
- net/sched: sch_qfq: Fix race condition on qfq_aggregate
(CVE-2025-38477 bsc#1247314).
- commit 7630d26
- x86/its: Enumerate Indirect Target Selection (ITS) bug (bsc#1242006 CVE-2024-28956).
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 42eb2aa
- HID: intel-ish-hid: Fix use-after-free issue in
ishtp_hid_remove() (git-fixes CVE-2025-21928 bsc#1240722).
- commit 1ea59c1
- sched, cpuset: Fix dl_cpu_busy() panic due to empty
cs->cpus_allowed (CVE-2022-50103 bsc#1244840).
- commit 42c9f5e
- btrfs: harden block_group::bg_list against list_del() races (CVE-2025-37856 bsc#1243068)
- commit b816dc5
- crypto: lzo - Fix compression buffer overrun (CVE-2025-38068 bsc#1245210)
- commit 7609c8c
- KVM: x86: Reset IRTE to host control if *new* route isn't postable
(bsc#1242960 CVE-2025-37885).
- commit eff0d4a
- KVM: x86: Disable posted interrupts for non-standard IRQs delivery modes
(bsc#242960 CVE-2025-37885).
- commit b7ec59d
- kernel-syms.spec: Drop old rpm release number hack (bsc#1247172).
- commit b4fa2d1
- virtio-net: ensure the received length does not exceed allocated
size (CVE-2025-38375 bsc#1247177).
- commit e965903
- vsock/vmci: Clear the vmci transport packet properly when
initializing it (CVE-2025-38403 bsc#1247141).
- commit 42a6e1c
- wifi: carl9170: do not ping device which has failed to load
firmware (CVE-2025-38420 bsc#1247279).
- commit 77ff409
- crypto: qat - resolve race condition during AER recovery
(bsc#1223638 CVE-2024-26974).
- crypto: qat - fix double free during reset (bsc#1223638
CVE-2024-26974).
- commit 839d708
- Update
patches.suse/sch_hfsc-make-hfsc_qlen_notify-idempotent.patch
(CVE-2025-37798 bsc#1242414 CVE-2025-38177 bsc#1245986).
- commit 9499075
- bdi: Fix up kabi for dev_name addition (bsc#1171844).
- bdi: add a ->dev_name field to struct backing_dev_info
(bsc#1171844).
- commit 2563dd2
- Squashfs: check return result of sb_min_blocksize (bsc#1247147
CVE-2025-38415).
- commit 83161f2
- RDMA/core: Always release restrack object (git-fixes)
- commit 1647262
- HID: core: ensure the allocated report buffer can contain the
reserved report ID (CVE-2025-38495 bsc#1247348).
- commit a99e88f
- HID: core: do not bypass hid_hw_raw_request (CVE-2025-38494
bsc#1247349).
- commit a6f63b8
- net/sched: Always pass notifications when child class becomes
empty (CVE-2025-38350 bsc#1246781).
- commit a358033
- usb: host: ohci-ppc-of: Fix refcount leak bug (CVE-2022-50033
bsc#1245139).
- commit 341200f
- crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent
kernel memory leak (CVE-2022-50226 bsc#1244860).
- commit aa9545e
- l2tp: Don't sleep and disable BH under writer-side
sk_callback_lock (git-fixes).
- Refresh
patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch.
- Refresh
patches.suse/l2tp-prevent-lockdep-issue-in-l2tp_tunnel_register.patch.
- commit eb080d7
- l2tp: fix a sock refcnt leak in l2tp_tunnel_register
(git-fixes).
- net: fix a concurrency bug in l2tp_tunnel_register()
(bsc#1205711 CVE-2022-4129).
- Refresh
patches.suse/l2tp-Serialize-access-to-sk_user_data-with-sk_callba.patch.
- Refresh
patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch.
- commit 72fa3a1
- loop: Check for overflow while configuring loop (bsc#1245121
CVE-2022-49993).
- blacklist.conf: Remove commit from blacklist
- commit bb8ea17
- jbd2: fix data-race and null-ptr-deref in
jbd2_journal_dirty_metadata() (bsc#1246253 CVE-2025-38337).
- commit 3af075b
- ext4: inline: fix len overflow in ext4_prepare_inline_data
(bsc#1245976 CVE-2025-38222).
- commit 30045aa
- __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under
mount_lock (bsc#1245151 CVE-2025-38058).
- commit cc3f42a
- usb: typec: altmodes/displayport: do not index invalid
pin_assignments (CVE-2025-38391 bsc#1247181).
- commit de59e61
- scsi: core: Fix unremoved procfs host directory regression
(git-fixes).
- scsi: core: Fix a procfs host directory removal regression
(git-fixes CVE-2023-53118 bsc#1242365).
- commit 8e14770
- scsi: core: Fix a source code comment (git-fixes).
This isn't super useful per se, but makes applying other patches easier.
- commit a0df70c
- Bluetooth: MGMT: Protect mgmt_pending list with its own lock
(CVE-2025-38117 bsc#1245695).
- commit 59a2ea0
- Refresh
patches.suse/can-dev-can_put_echo_skb-don-t-crash-kernel-if-can_priv-ec.patch.
Fix the following warning:
drivers/net/can/dev.c: In function 'can_put_echo_skb':
drivers/net/can/dev.c:451:3: warning: 'return' with a value, in function returning void
- commit 3c66160
- kabi fix for perf/aux: Fix AUX buffer serialization
(bsc#1230581, CVE-2024-46713).
- perf/aux: Fix AUX buffer serialization (bsc#1230581,
CVE-2024-46713).
- commit a370cdb
- iommu/arm-smmu: fix possible null-ptr-deref in
arm_smmu_device_probe() (CVE-2022-49323 bsc#1238400).
- commit 1c0f036
- nvme-tcp: sanitize request list handling (CVE-2025-38264
bsc#1246387).
- commit eab9cf4
- iommu/arm-smmu-v3: check return value after calling
platform_get_resource() (CVE-2022-49319 bsc#1238374).
- commit d41ddd7
- RDMA/core: Update CMA destination address on rdma_resolve_addr (bsc#1210629 CVE-2023-2176)
- commit 45a243e
- Squashfs: check the inode number is not the invalid value of
zero (bsc#1223634 CVE-2024-26982).
- commit d6425c9
- RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction (CVE-2025-38211 bsc#1246008)
- commit e7cb52a
- rpm/kernel-subpackage-spec: Skip brp-strip-debug to avoid file truncation (bsc#1246879)
Put the same workaround to avoid file truncation of vmlinux and co in
kernel-default-base package, too.
- commit 2329734
- Bluetooth: Replace BT_DBG with bt_dev_dbg for management support
(CVE-2025-38117 bsc#1245695).
- Refresh
patches.suse/Bluetooth-MGMT-Fix-not-checking-if-BT_HS-is-enabled.patch.
- commit c096742
- Bluetooth: Fix spelling mistakes (CVE-2025-38117 bsc#1245695).
- commit 82a31bb
- rpm/kernel-binary.spec.in: Ignore return code from ksymtypes compare
When using suse-kabi-tools, the RPM build invokes 'ksymvers compare' to
compare the resulting symbol CRCs with the reference data. If the values
differ, it then invokes 'ksymtypes compare' to provide a detailed report
explaining why the symbols differ. The build expects the latter
'ksymtypes compare' command to always return zero, even if the two
compared kABI corpuses are different.
This is currently the case for 'ksymtypes compare'. However, I plan to
update the command to return a non-zero code when the comparison detects
any differences. This should ensure consistent behavior with 'ksymvers
compare'.
Since the build uses 'ksymtypes compare' only for more detailed
diagnostics, ignore its return code.
- commit 5ac1381
- net: atm: fix /proc/net/atm/lec handling (CVE-2025-38180
bsc#1245970).
- net: atm: add lec_mutex (CVE-2025-38323 bsc#1246473).
- net: atm: clean up a range check (CVE-2025-38323 bsc#1246473).
- commit 273d1a3
- Bluetooth: fix appearance typo in mgmt.c (CVE-2025-38117
bsc#1245695).
- commit 7c5fd29
- Bluetooth: mgmt: Use struct_size() helper (CVE-2025-38117
bsc#1245695).
- commit 27a3626
- Bluetooth: Use struct_size() helper (CVE-2025-38117
bsc#1245695).
- commit a97aa39
- Bluetooth: mgmt: Use struct_size() helper (CVE-2025-38117
bsc#1245695).
- commit e452cf2
- Bluetooth: Mark expected switch fall-throughs (CVE-2025-38117
bsc#1245695).
- commit 524b16d
- Refresh
patches.suse/ipv6-mcast-add-RCU-protection-to-mld_newpack.patch.
- commit b9c9349
- fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()
(CVE-2025-38312 bsc#1246386).
- commit aea2659
- kABI workaround for bluetooth hci_dev changes (CVE-2025-38250
bsc#1246182).
- commit 3a445ce
- Bluetooth: hci_core: Fix use-after-free in vhci_flush()
(CVE-2025-38250 bsc#1246182).
- commit 0b02672
- fbcon: Make sure modelist not set on unregistered console (bsc#1245952 CVE-2025-38198)
- commit f64b2f2
- serial: mctrl_gpio: split disable_ms into sync and no_sync APIs
(CVE-2025-38040 bsc#1245078).
- kabi: serial: mctrl_gpio: split disable_ms into sync and
no_sync APIs (CVE-2025-38040 bsc#1245078).
- commit 3c2fda4
- btrfs: fix deadlock when cloning inline extents and using qgroups (CVE-2021-46987 bsc#1220704)
- commit 68d125c
- btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref (CVE-2025-38034 bsc#1244792)
- commit c1bc05f
- btrfs: do not BUG_ON() when freeing tree block after error (CVE-2024-44963 1230216)
- commit c7b8e6b
- net_sched: red: fix a race in __red_change() (CVE-2025-38108
bsc#1245675).
- net: stmmac: make sure that ptp_rate is not 0 before configuring
timestamping (CVE-2025-38126 bsc#1245708).
- bpf: fix ktls panic with sockmap (CVE-2025-38166 bsc#1245758).
- commit 1452ad9
- perf: Fix sample vs do_exit() (bsc#1246547 CVE-2025-38424 bsc#1247293)
- commit 887b64f
- Update
patches.suse/net-clear-the-dst-when-changing-skb-protocol.patch
(bsc#1245954 CVE-2025-38192).
Fix incorrect CVE reference.
- commit 8a5f77c
- patches.suse/ext4-fix-warning-in-ext4_iomap_begin-as-race-begin-as-race-between.patch:
Remove the patch as it's not needed and is causing deadlocks
(bsc#1246459, bsc#1245115, CVE-2022-50082)
- commit fab7cb7
- net_sched: sch_sfq: reject invalid perturb period
(CVE-2025-38193 bsc#1245945).
- commit b90f28d
- ipc: fix to protect IPCS lookups using RCU (CVE-2025-38212
bsc#1246029).
- commit 3438ce5
- calipso: unlock rcu before returning -EAFNOSUPPORT
(CVE-2025-38147 bsc#1245768).
- calipso: Don't call calipso functions for AF_INET sk
(CVE-2025-38147 bsc#1245768).
- commit 6d3ad82
- i40e: fix MMIO write access to an invalid page in i40e_clear_hw
(CVE-2025-38200 bsc#1246045).
- net: cadence: macb: Fix a possible deadlock in macb_halt_tx
(CVE-2025-38094 bsc#1245649).
- commit 3fe4112
- drm/amd/pp: Fix potential NULL pointer dereference in
atomctrl_initialize_mc_reg_table (CVE-2025-38319 bsc#1246243).
- commit 28370d4
- ALSA: usb-audio: Fix out-of-bounds read in
snd_usb_get_audioformat_uac3() (CVE-2025-38249 bsc#1246171).
- commit a7d7572
- iopoll: Introduce read_poll_timeout_atomic macro (CVE-2025-38094
bsc#1245649).
- net: cadence: Fix a sleep-in-atomic-context bug in
macb_halt_tx() (CVE-2025-38094 bsc#1245649).
- commit 94f52a4
- net: clear the dst when changing skb protocol (bsc#1245954
CVE-2024-49861).
- commit c3ead22
- wifi: ath9k_htc: Abort software beacon handling if disabled
(CVE-2025-38157 bsc#1245747).
- commit 2580def
- RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction (CVE-2025-38161 bsc#1245777)
- commit 884e454
- calipso: Fix null-ptr-deref in calipso_req_{set,del}attr()
(CVE-2025-38181 bsc#1246000).
- net_sched: sch_sfq: fix a potential crash on gso_skb handling
(CVE-2025-38115 bsc#1245689).
- commit 4ac1c90
- Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt
(bsc#1238160 CVE-2022-49138).
- commit a00d68a
- net: Fix TOCTOU issue in sk_is_readable() (CVE-2025-38112
bsc#1245668).
- commit 5d4114f
- Bluetooth: hci_event: Fix checking for invalid handle on error
status (bsc#1238160 CVE-2022-49138).
- commit c843371
- vgacon: Add check for vc_origin address range in vgacon_scroll()
(CVE-2025-38213 bsc#1246037).
- commit 22c4880
- ALSA: usb-audio: Kill timer properly at removal (CVE-2025-38105
bsc#1245682).
- commit 917cf9d
- wifi: mac80211: Fix UAF in ieee80211_scan_rx() (CVE-2022-49934
bsc#1245051).
- commit cf69513
- rpm/mkspec: Fix missing kernel-syms-rt creation (bsc#1244337)
- commit 630f139
- nbd: don't allow reconnect after disconnect (CVE-2025-21731 bsc#1237881).
- commit 8a4b419
- vhost-scsi: protect vq->log_used with vq->mutex (CVE-2025-38074
bsc#1244735).
- commit 18cd652
- Bluetooth: hci_event: Ignore multiple conn complete events
(bsc#1238160 CVE-2022-49138).
- commit a0784d3
- virtgpu: don't reset on shutdown (git-fixes).
- commit b2d9b68
- Refresh
patches.suse/kabi-fix-for-prevent-bpf-program-recursion-for-raw-tracepoint-probes.patch.
Fix NULL pointer deference leading to a kernel panic/oops (bsc#1245948).
- commit 7935351
- crypto: algif_hash - fix double free in hash_accept
(CVE-2025-38079 bsc#1245217).
- commit 288b933
- virtio: break and reset virtio devices on device_shutdown()
(CVE-2025-38064 bsc#1245201).
- commit 1ec66e0
- drm/amd/display: clear optc underflow before turn off odm clock (bsc#1245060 CVE-2022-49969)
- commit 360b84f
- can: dev: can_put_echo_skb(): don't crash kernel if
can_priv::echo_skb is accessed out of bounds (CVE-2023-52878
bsc#1225000).
- commit 71fb63a
- smb: client: Fix use-after-free in cifs_fill_dirent
(CVE-2025-38051 bsc#1244750).
- commit 1258b98
- cxl: Fix a memory leak in an error handling path (CVE-2022-50025
bsc#1245132).
- commit fe62ac8
- driver core: fix potential deadlock in __driver_attach
(CVE-2022-50149 bsc#1244883).
- commit 0cc27e4
- scsi: lpfc: Fix possible memory leak when failing to issue
CMF WQE (bsc#1245073 CVE-2022-50027).
- commit e689b05
- nvmet-tcp: don't restore null sk_state_change (bsc#1244801
CVE-2025-38035).
- commit eece831
- 9p/fd: fix issue of list_del corruption in p9_fd_cancel() (CVE-2022-49768 bsc#1242446).
- commit 29f06d8
- blk-mq: Fixup kABI due to added parameter to bio_merge
(bsc#1220631 CVE-2021-46984).
- commit de58150
- scsi: lpfc: Prevent buffer overflow crashes in debugfs with
malformed user input (bsc#1245265 CVE-2022-50030).
- commit e1b77ba
- kyber: fix out of bounds access when preempted (CVE-2021-46984
bsc#1220631).
- blacklist.conf: Remove from blacklist
- Refresh patches.kabi/bfq_depth_updated-fix-kABI.patch
- commit 8efa3ed
- ext4: fix warning in ext4_iomap_begin as race between bmap
and write (bsc#1245115 CVE-2022-50082).
- commit 06b2a8c
- kABI workaround for xsk: Fix race condition in AF_XDP generic
RX path (CVE-2025-37920 bsc#1243479).
- commit cd1f0aa
- xsk: Fix race condition in AF_XDP generic RX path (bsc#1243479
CVE-2025-37920).
- commit 0e83480
- vt: Clear selection before changing the font (CVE-2022-49948
bsc#1245058).
- commit 3e5249e
- 9p: trans_fd/p9_conn_cancel: drop client lock earlier (CVE-2022-49768 bsc#1242446).
- commit 4d2a2e9
- rpm: Drop support for kabi/arch/ignore-flavor (bsc#1249186)
It's not used in any active branches and it cannot solve contemporary
problems.
- commit f86a16a
- net: pktgen: fix access outside of user given buffer in
pktgen_thread_write() (CVE-2025-38061 bsc#1245440).
- commit fb0f1a2
- net: vlan: don't propagate flags on open (CVE-2025-23163
bsc#1242837).
- commit d0e8595
- scsi: storvsc: Increase the timeouts to storvsc_timeout (bsc#1245455).
- scsi: storvsc: Don't report the host packet status as the hv status (git-fixes).
- commit adbc421
- kernel-obs-qa: Do not depend on srchash when qemu emulation is used
In this case the dependency is never fulfilled
Fixes: 485ae1da2b88 ("kernel-obs-qa: Use srchash for dependency as well")
- commit a840f87
- firmware: arm_scpi: Ensure scpi_info is not assigned if the
probe fails (CVE-2022-50087 bsc#1245119).
- commit ec5ba42
- Update
patches.suse/0001-drm-msm-mdp5-Fix-global-state-lock-backoff.patch
(bsc#1238275 CVE-2022-50173 bsc#1244992).
- Update
patches.suse/0005-video-fbdev-amba-clcd-Fix-refcount-leak-bugs.patch
(bsc#1154048 CVE-2022-50109 bsc#1244884).
- Update
patches.suse/0007-video-fbdev-arkfb-Fix-a-divide-by-zero-bug-in-ark_se.patch
(bsc#1154048 CVE-2022-50102 bsc#1244838).
- Update
patches.suse/0008-dm-thin-fix-use-after-free-crash-in-dm_sm_register_t.patch
(git-fixes CVE-2022-50092 bsc#1244848).
- Update
patches.suse/0008-video-fbdev-vt8623fb-Check-the-size-of-screen-before.patch
(bsc#1154048 CVE-2022-50101 bsc#1244839).
- Update
patches.suse/0009-video-fbdev-arkfb-Check-the-size-of-screen-before-me.patch
(bsc#1154048 CVE-2022-50099 bsc#1244842).
- Update
patches.suse/0010-dm-raid-fix-address-sanitizer-warning-in-raid_status.patch
(git-fixes CVE-2022-50084 bsc#1245117).
- Update
patches.suse/0010-video-fbdev-s3fb-Check-the-size-of-screen-before-mem.patch
(bsc#1154048 CVE-2022-50097 bsc#1244845).
- Update
patches.suse/0011-dm-raid-fix-address-sanitizer-warning-in-raid_resume.patch
(git-fixes CVE-2022-50085 bsc#1245147).
- Update
patches.suse/0011-fbdev-fb_pm2fb-Avoid-potential-divide-by-zero-error.patch
(bsc#1154048 CVE-2022-49978 bsc#1245195).
- Update
patches.suse/0080-drivers-md-fix-a-potential-use-after-free-bug.patch
(git-fixes CVE-2022-50022 bsc#1245131).
- Update
patches.suse/Bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch
(CVE-2023-1989 bsc#1210336 CVE-2023-53145 bsc#1243047
CVE-2023-53063 bsc#1242216).
- Update
patches.suse/Input-iforce-wake-up-after-clearing-IFORCE_XMIT_RUNN.patch
(git-fixes CVE-2022-49954 bsc#1244976).
- Update
patches.suse/PCI-dwc-Deallocate-EPC-memory-on-dw_pcie_ep_init-err.patch
(git-fixes CVE-2022-50146 bsc#1244788).
- Update
patches.suse/USB-core-Prevent-nested-device-reset-calls.patch
(bsc#1206664 CVE-2022-4662 CVE-2022-49936 bsc#1244984).
- Update
patches.suse/arm64-fix-oops-in-concurrently-setting-insn_emulation-sysctls.patch
(git-fixes CVE-2022-50206 bsc#1245152).
- Update
patches.suse/ath9k-fix-use-after-free-in-ath9k_hif_usb_rx_cb.patch
(CVE-2022-1679 bsc#1199487 CVE-2022-50179 bsc#1244886).
- Update
patches.suse/btrfs-unset-reloc-control-if-transaction-commit-fail.patch
(bsc#1212051 CVE-2023-3111 CVE-2022-50067 bsc#1245047).
- Update
patches.suse/cifs-fix-small-mempool-leak-in-SMB2_negotiate-.patch
(bsc#1190317 CVE-2022-49938 bsc#1244820).
- Update
patches.suse/ext4-add-EXT4_INODE_HAS_XATTR_SPACE-macro-in-xattr.h.patch
(bsc#1206878 CVE-2022-50083 bsc#1244968).
- Update
patches.suse/ext4-avoid-resizing-to-a-partial-cluster-size.patch
(bsc#1206880 CVE-2022-50020 bsc#1245129).
- Update
patches.suse/ftrace-Fix-NULL-pointer-dereference-in-is_ftrace_trampoline-when-ftrace-is-dead.patch
(git-fixes CVE-2022-49977 bsc#1244936).
- Update
patches.suse/iommu-vt-d-avoid-invalid-memory-access-via-node_online-NUMA_NO_N
(git-fixes CVE-2022-50093 bsc#1244849).
- Update
patches.suse/jbd2-fix-assertion-jh-b_frozen_data-NULL-failure-whe.patch
(bsc#1202716 CVE-2022-50126 bsc#1244813).
- Update patches.suse/kcm-fix-strp_init-order-and-cleanup.patch
(git-fixes CVE-2022-49957 bsc#1244966).
- Update
patches.suse/kprobes-don-t-call-disarm_kprobe-for-disabled-kprobes.patch
(git-fixes CVE-2022-50008 bsc#1245009).
- Update
patches.suse/locking-csd_lock-Change-csdlock_debug-from-early_par.patch
(git-fixes CVE-2022-50091 bsc#1244885).
- Update patches.suse/md-call-__md_stop_writes-in-md_stop.patch
(git-fixes CVE-2022-49987 bsc#1245024).
- Update patches.suse/md-raid10-fix-KASAN-warning.patch (git-fixes
CVE-2022-50211 bsc#1245140).
- Update
patches.suse/media-mceusb-Use-new-usb_control_msg_-routines.patch
(CVE-2022-3903 bsc#1205220 CVE-2022-49937 bsc#1245057).
- Update
patches.suse/msft-hv-2639-scsi-storvsc-Remove-WQ_MEM_RECLAIM-from-storvsc_erro.patch
(git-fixes CVE-2022-49986 bsc#1244948).
- Update
patches.suse/net-tap-NULL-pointer-derefence-in-dev_parse_header_p.patch
(git-fixes CVE-2022-50073 bsc#1244978).
- Update
patches.suse/netfilter-nf_tables-do-not-allow-SET_ID-to-refer-to-.patch
(bsc#1202095 CVE-2022-2586 CVE-2022-50213 bsc#1244867).
- Update
patches.suse/pinctrl-devicetree-fix-refcount-leak-in-pinctrl_dt_t.patch
(bsc#1242154 CVE-2024-36959 bsc#1225839).
- Update
patches.suse/powerpc-64-Init-jump-labels-before-parse_early_param.patch
(bsc#1065729 CVE-2022-50012 bsc#1245125).
- Update patches.suse/powerpc-pci-Fix-get_phb_number-locking.patch
(bsc#1065729 CVE-2022-50045 bsc#1244967).
- Update
patches.suse/powerpc-xive-Fix-refcount-leak-in-xive_get_max_prio.patch
(fate#322438 git-fixess CVE-2022-50104 bsc#1244836).
- Update
patches.suse/s390-fix-double-free-of-GS-and-RI-CBs-on-fork-failure
(bsc#1203254 LTC#199911 CVE-2022-49990 bsc#1245006).
- Update
patches.suse/scsi-qla2xxx-Fix-crash-due-to-stale-SRB-access-aroun.patch
(bsc#1201958 CVE-2022-50098 bsc#1244841).
- Update
patches.suse/scsi-sg-Allow-waiting-for-commands-to-complete-on-removed-device.patch
(git-fixes CVE-2022-50215 bsc#1245138).
- Update
patches.suse/spmi-trace-fix-stack-out-of-bound-access-in-SPMI-tracing-functions.patch
(git-fixes CVE-2022-50094 bsc#1244851).
- Update
patches.suse/staging-rtl8712-fix-use-after-free-bugs.patch
(CVE-2022-4095 bsc#1205514 CVE-2022-49956 bsc#1244969).
- Update
patches.suse/usb-host-Fix-refcount-leak-in-ehci_hcd_ppc_of_probe.patch
(git-fixes CVE-2022-50153 bsc#1244786).
- Update
patches.suse/usb-ohci-nxp-Fix-refcount-leak-in-ohci_hcd_nxp_probe.patch
(git-fixes CVE-2022-50152 bsc#1244783).
- Update
patches.suse/usbnet-Fix-linkwatch-use-after-free-on-disconnect.patch
(git-fixes CVE-2022-50220 bsc#1245348).
- Update
patches.suse/virtio-gpu-fix-a-missing-check-to-avoid-NULL-derefer.patch
(git-fixes CVE-2022-50181 bsc#1244901).
- Update
patches.suse/virtio_net-fix-memory-leak-inside-XPD_TX-with-mergea.patch
(git-fixes CVE-2022-50065 bsc#1244986).
- commit 4b076ee
- selinux: Add boundary check in put_entry() (CVE-2022-50200
bsc#1245149).
- commit 90c9727
- RDMA/hfi1: fix potential memory leak in setup_base_ctxt() (CVE-2022-50134 bsc#1244802)
- commit 544eb52
- tracing: Fix compilation warning on arm32 (bsc#1243551).
- commit f83d64b
- tracing: Fix oob write in trace_seq_to_buffer() (CVE-2025-37923
bsc#1243551).
- commit ab5c2ad
- net_sched: prio: fix a race in prio_tune() (CVE-2025-38083
bsc#1245183).
- commit 4ff0382
- tracing: Fix use-after-free in print_graph_function_flags
during tracer switching (CVE-2025-22035 bsc#1241544).
- commit 93e9f48
- iavf: Fix adminq error handling (CVE-2022-50055 bsc#1245039).
- commit cf4815a
- ftrace: Return the first found result in lookup_rec()
(bsc#1226837).
- commit 548c54e
- ftrace: Fix possible use-after-free issue in ftrace_location()
(CVE-2024-38588 bsc#1226837).
- ftrace: Fix possible warning on checking all pages used in
ftrace_process_locs() (bsc#1226837).
- blacklist.conf: Remove the commit
- ftrace: Separate out functionality from ftrace_location_range()
(bsc#1226837).
- ftrace: Zero out ftrace hashes when a module is removed (bsc#1226837).
- commit ca17def
- Check for losing the race against dp_altmode_probe
(CVE-2024-35790 bsc#1224712).
This is a nonstandard fix because the upstream fix
includes a cleanup that requires infrastructure
that breaks kABI by changing struct device_driver
- commit ffe9de9
- bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser() (CVE-2023-53133 bsc#1242423)
- commit 4d2b740
- iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
(CVE-2025-37927 bsc#1243620).
- iommu/amd: Fix ivrs_acpihid cmdline parsing code (CVE-2025-37927
bsc#1243620).
- commit 3614667
- Remove host-memcpy-hack.h
This might have been usefult at some point but we have more things that
depend on specific library versions today.
- commit 0396c23
- Remove compress-vmlinux.sh
/usr/lib/rpm/brp-suse.d/brp-99-compress-vmlinux was added in
pesign-obs-integration during SLE12 RC. This workaround can be removed.
- commit 19caac0
- Remove try-disable-staging-driver
The config for linux-next is autogenerated from master config, and
defaults filled for missing options. This is unlikely to enable any
staging driver in the first place.
- commit a6f21ed
- scsi: target: Fix WRITE_SAME No Data Buffer crash
(CVE-2022-21546, bsc#1242243).
- commit 0b27e73
- kABI fix for net: xfrm: Localize sequence counter per network
namespace (CVE-2024-57982 bsc#1237913).
- commit e37d325
- xfrm: state: fix out-of-bounds read during lookup
(CVE-2024-57982 bsc#1237913).
- net: xfrm: Localize sequence counter per network namespace
(CVE-2024-57982 bsc#1237913).
- commit 03cb718
- RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug (CVE-2025-38024 bsc#1245025)
- commit 4f2eb61
- nfs: handle failure of nfs_get_lock_context in unlock path
(bsc#1245004 CVE-2025-38023).
- commit 1be83c3
- libnvdimm/labels: Fix divide error in nd_label_data_init()
(bsc#1244743, CVE-2025-38072).
- commit dacc95b
- scsi: target: tcm_loop: Fix possible name leak in
tcm_loop_setup_hba_bus() (CVE-2022-49780 bsc#1242262).
- commit 6710526
- Set CPUID_8000_0021_EAX to the right value (20)
This is the word in which individual feature flags are defined,
so the cpuid_leaf number must match.
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- Refresh
patches.suse/x86-bhi-Add-support-for-clearing-branch-history-at-syscall.patch.
- Refresh
patches.suse/x86-cpufeature-Add-missing-leaf-enumeration.patch.
- commit c63ac04
- ALSA: pcm: Fix race of buffer access at PCM OSS layer
(CVE-2025-38078 bsc#1244737).
- commit 7c6d995
- Move upstreamed sound patch into sorted section
- commit 4436fa8
- packaging: Add support for suse-kabi-tools
The current workflow to check kABI stability during the RPM build of SUSE
kernels consists of the following steps:
* The downstream script rpm/modversions unpacks the consolidated kABI
symtypes reference data from kabi/<arch>/symtypes-<flavor> and creates
individual symref files.
* The build performs a regular kernel make. During this operation, genksyms
is invoked for each source file. The tool determines type signatures of
all exports within the file, reports any differences compared to the
associated symref reference, calculates symbol CRCs from the signatures
and writes new type data into a symtypes file.
* The script rpm/modversions is invoked again, this time it packs all new
symtypes files to a consolidated kABI file.
* The downstream script rpm/kabi.pl checks symbol CRCs in the new build and
compares them to a reference from kabi/<arch>/symvers-<flavor>, taking
kabi/severities into account.
suse-kabi-tools is a new set of tools to improve the kABI checking process.
The suite includes two tools, ksymtypes and ksymvers, which replace the
existing scripts rpm/modversions and rpm/kabi.pl, as well as the comparison
functionality previously provided by genksyms. The tools have their own
source repository and package.
The tools provide faster operation and more detailed, unified output. In
addition, they allow the use of the new upstream tool gendwarfksyms, which
lacks any built-in comparison functionality.
The updated workflow is as follows:
* The build performs a regular kernel make. During this operation, genksyms
(gendwarfksyms) is invoked as usual, determinining signatures and CRCs of
all exports and writing the type data to symtypes files. However,
genksyms no longer performs any comparison.
* 'ksymtypes consolidate' packs all new symtypes files to a consolidated
kABI file.
* 'ksymvers compare' checks symbol CRCs in the new build and compares them
to a reference from kabi/<arch>/symvers-<flavor>, taking kabi/severities
into account. The tool writes its result in a human-readable form on
standard output and also writes a list of all changed exports (not
ignored by kabi/severities) to the changed-exports file.
* 'ksymtypes compare' takes the changed-exports file, the consolidated kABI
symtypes reference data from kabi/<arch>/symtypes-<flavor> and the new
consolidated data. Based on this data, it produces a detailed report
explaining why the symbols changed.
The patch enables the use of suse-kabi-tools via rpm/config.sh, providing
explicit control to each branch. To enable the support, set
USE_SUSE_KABI_TOOLS=Yes in the config file.
- commit a2c6f89
- netfilter: allow exp not to be removed in nf_ct_find_expectation
(CVE-2023-52927 bsc#1239644).
- commit c88f971
- kernel-source: Remove log.sh from sources
- commit 96bd779
- media: pvrusb2: fix uaf in pvr2_context_set_notify
(CVE-2024-26875 bsc#1223118).
- commit 9270436
- drm/amdkfd: Fix an illegal memory access (CVE-2023-53090
bsc#1242753).
- commit 8280475
- can: bcm: add locking for bcm_op runtime updates (CVE-2025-38004
bsc#1244274).
- commit 27f3405
- scsi: drivers: base: Propagate errors through the transport component (bsc#1242548)
- commit 19a4dc6
- scsi: drivers: base: Support atomic version of attribute_container_device_trigger (bsc#1242548)
- commit 250283f
- sch_hfsc: Fix qlen accounting bug when using peek in
hfsc_enqueue() (CVE-2025-38000 bsc#1244277).
- commit 8634486
- net_sched: Flush gso_skb list too during ->change()
(CVE-2025-37992 bsc#1243698).
- ipvs: fix uninit-value for saddr in do_output_route4
(CVE-2025-37961 bsc#1243523).
- net: tls: explicitly disallow disconnect (CVE-2025-37756
bsc#1242515).
- net_sched: Prevent creation of classes with TC_H_ROOT
(CVE-2025-21971 bsc#1240799).
- vlan: enforce underlying device type (CVE-2025-21920
bsc#1240686).
- kcm: close race conditions on sk_receive_queue (CVE-2022-49814
bsc#1242498).
- wifi: cfg80211: fix memory leak in query_regdb_file()
(CVE-2022-49881 bsc#1242481).
- ipvs: fix WARNING in ip_vs_app_net_cleanup() (CVE-2022-49917
bsc#1242406).
- commit 225b1ce
- net_sched: sch_fifo: implement lockless __fifo_dump() (bsc#1237312)
- commit 619fd3b
- netfilter: bridge: replace physindev with physinif in
nf_bridge_info (CVE-2024-35839 bsc#1224726).
- Refresh patches.kabi/kabi-add-__nf_bridge_get_physindev-for-kabi.patch.
- commit ec55ccf
- kabi: add __nf_bridge_get_physindev() for kabi
(bsc#1224726,CVE-2024-35839).
- commit 8066fc3
- tipc: fix memory leak in tipc_link_xmit (CVE-2025-37757 bsc#1242521)
- commit ca38369
- net: sched: Fix use after free in red_enqueue() (CVE-2022-49921 bsc#1242359)
- commit 91e83c2
- netfilter: propagate net to nf_bridge_get_physindev
(CVE-2024-35839 bsc#1224726).
- Refresh patches.kabi/kabi-add-__nf_queue_get_refs-for-kabi-compliance.patch.
- commit 3ffae8c
- serial: core: fix transmit-buffer reset and memleak (bsc#1227768
CVE-2021-47527).
- commit 1772922
- bnxt_en: Fix out-of-bound memcpy() during ethtool -w
(CVE-2025-37911 bsc#1243469).
- mlxsw: spectrum_acl_tcam: Fix stack corruption (CVE-2024-26586
bsc#1220243).
- net/mlx5: Update error handler for UCTX and UMEM (CVE-2021-47212
bsc#1222709).
- commit 5027586
- module: ensure that kobject_put() is safe for module type kobjects (CVE-2025-37995 bsc#1243827)
- commit 31568b0
- mkspec: Exclude rt flavor from kernel-syms dependencies (bsc#1244337).
- commit 7c95ae0
- Refresh
patches.suse/kabi-fix-for-prevent-bpf-program-recursion-for-raw-tracepoint-probes.patch.
Fix the kernel Oops (bsc#1244317)
- commit 6a26caf
- mnt: fix __detach_mounts infinite loop (bsc#1242140).
- commit 973877c
- MyBS: Do not build kernel-obs-qa with limit_packages
Fixes: 58e3f8c34b2b ("bs-upload-kernel: Pass limit_packages also on multibuild")
- commit f4c6047
- MyBS: Simplify qa_expr generation
Start with a 0 which makes the expression valid even if there are no QA
repositories (currently does not happen). Then separator is always
needed.
- commit e4c2851
- MyBS: Correctly generate build flags for non-multibuild package limit
(bsc# 1244241)
Fixes: 0999112774fc ("MyBS: Use buildflags to set which package to build")
- commit 27588c9
- bs-upload-kernel: Pass limit_packages also on multibuild
Fixes: 0999112774fc ("MyBS: Use buildflags to set which package to build")
Fixes: 747f601d4156 ("bs-upload-kernel, MyBS, Buildresults: Support multibuild (JSC-SLE#5501, boo#1211226, bsc#1218184)")
- commit 8ef486c
- ftrace: Avoid potential division by zero in function_stat_show()
(CVE-2025-21898 bsc#1240610).
- commit f3b653b
- kABI: workaround "bpf: Prevent bpf program recursion for raw
tracepoint probes" changes (bsc#1242301 CVE-2022-49764).
- commit 06373a9
- nfc: nci: free rx_data_reassembly skb on NCI device cleanup
(CVE-2024-26825 bsc#1223065).
- commit e2bddb4
- ptp: Fix possible memory leak in ptp_clock_register()
(CVE-2021-47455 bsc#1225254).
- Refresh patches.kabi/ptp_clock-kABI-workaround.patch.
- commit e9de86b
- RDMA/srpt: Do not register event handler until srpt device is fully setup (CVE-2024-26872 bsc#1223115)
- commit cad3736
- driver core: fix potential NULL pointer dereference in
dev_uevent() (CVE-2025-37800 bsc#1242849).
- driver core: introduce device_set_driver() helper
(CVE-2025-37800 bsc#1242849).
- commit f8f225c
- Drop rejected CVE fix for driver core
Delete
patches.suse/driver-core-Fix-uevent_show-vs-driver-detach-race.patch
as it was reverted in the upstream (and CVE was rejected).
Another form of the fix will follow.
- commit c791e65
- kernel-source: Do not use multiple -r in sed parameters
This usage is enabled in commit b18d64d
(sed: allow multiple (non-conflicting) -E/-r parameters, 2016-07-31)
only available since sed 4.3
Fixes: dc2037cd8f94 ("kernel-source: Also replace bin/env"
- commit 91ad98e
- block: fix resource leak in blk_register_queue() error path (CVE-2025-37980 bsc#1243522)
- commit 65b2595
- openvswitch: Fix unsafe attribute parsing in output_userspace() (CVE-2025-37998 bsc#1243836)
- commit 1de5c37
- dm-bufio: don't schedule in atomic context (CVE-2025-37928 bsc#1243621)
- commit 8d6e517
- mtd: inftlcore: Add error check for inftl_read_oob() (CVE-2025-37892 bsc#1243536)
- commit 54793bb
- wifi: wl1251: fix memory leak in wl1251_tx_work (CVE-2025-37982 bsc#1243524)
- commit 9ed11b8
- netfilter: nf_tables: fix crash when nf_trace is enabled
(git-fixes CVE-2022-49622 bsc#1239042).
- commit 1ebebaa
- netfilter: nf_tables: avoid skb access on nf_stolen
(CVE-2022-49622 bsc#1239042).
- commit 3d1f851
- netfilter: nf_tables: consolidate rule verdict trace call (bsc#1239042).
- commit a2784df
- netfilter: nf_tables: remove old nf_log based tracing (bsc#1239042).
- Refresh
patches.suse/netfilter-nf_tables-check-the-result-of-dereferencin.patch.
- Refresh
patches.suse/netfilter-nf_tables-use-WARN_ON_ONCE-instead-of-BUG_.patch.
- commit c5a2d73
- KVM: SVM: fix panic on out-of-bounds guest IRQ (bsc#1238167 CVE-2022-49154).
- commit 930b864
- Update tags in
patches.suse/ocfs2-fix-data-corruption-after-failed-write.patch
(bsc#1208542 CVE-2023-53081 bsc#1242281).
- commit 54cff45
- ext4: update s_journal_inum if it changes after journal replay
(bsc#1242767 CVE-2023-53091).
- commit 36a043e
- ext4: fix BUG_ON() when directory entry has invalid rec_len
(bsc#1242733 CVE-2022-49879).
- commit dfbcdb4
- scsi: pm80xx: Avoid leaking tags when processing
OPC_INB_SET_CONTROLLER_CONFIG command (bsc#1220883
cve-2023-52500 CVE-2023-52500).
- commit 8a3dd0b
- ata: libata-core: fix NULL pointer deref in
ata_host_alloc_pinfo() (bsc#1239071 CVE-2022-49731).
- commit f8e7ddf
- l2tp: fix lockdep splat (CVE-2023-53020 bsc#1240224).
- l2tp: Avoid possible recursive deadlock in
l2tp_tunnel_register() (CVE-2023-53020 bsc#1240224).
- l2tp: prevent lockdep issue in l2tp_tunnel_register()
(CVE-2023-53020 bsc#1240224).
- l2tp: close all race conditions in l2tp_tunnel_register()
(CVE-2023-53020 bsc#1240224).
- blacklist.conf: remove 0b2c59720e65885a394a017d0cf9cab118914682
it is a bit unclear why it was there but it should not be there any more
- l2tp: define helper for parsing struct sockaddr_pppol2tp*
(CVE-2023-53020 bsc#1240224).
- commit 6df99cf
- Fix bug reference in patches.suse/net_sched-sch_sfq-use-a-temporary-work-area-for-vali.patch (bsc#1242504)
- commit 14f3c70
- x86/bugs: Fix BHI retpoline check (git-fixes).
- commit 67aed4a
- x86/bugs: Fix BHI handling of RRSBA (git-fixes).
- Refresh
patches.suse/x86-bhi-do-not-set-BHI_DIS_S-in-32-bit-mode.patch.
- commit dab1e97
- x86/bugs: Cache the value of MSR_IA32_ARCH_CAPABILITIES (git-fixes).
- commit 01a0a7a
- x86/bugs: Fix return type of spectre_bhi_state() (git-fixes).
- commit 198eac5
- btrfs: don't BUG_ON() when 0 reference count at
btrfs_lookup_extent_info() (bsc#1230786 CVE-2024-46751).
- commit ed57497
- HID: pidff: Fix null pointer dereference in pidff_find_fields (CVE-2025-37862 bsc#1242982)
- commit 3dd1249
- PCI: Fix reference leak in pci_register_host_bridge() (CVE-2025-37836 bsc#1242957)
- commit ed65adb
- usb: dwc3: gadget: check that event count does not exceed event buffer length (CVE-2025-37810 bsc#1242906)
- commit b2856a0
- cifs: avoid NULL pointer dereference in dbg call (CVE-2025-37844 bsc#1242946)
- commit 32900ee
- tpm: do not start chip while suspended (CVE-2025-23149 bsc#1242758)
- commit 0620cc8
- Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch.
Fix a couple of issues with this backport, namely:
1. Wrong upstream commit id used
2. Missing hunk dealing with RETPOLINE being enabled on RRSBA CPUs, thus
obviating the need to have BHI mitigation explicitly enabled.
- commit daaf354
- Update
patches.suse/0084-dm-ioctl-fix-misbehavior-if-list_versions-races-with-module-loading.patch
(git-fixes CVE-2022-49771 bsc#1242686).
- Update
patches.suse/Bluetooth-L2CAP-Fix-use-after-free-caused-by-l2cap_r.patch
(CVE-2022-3564 bsc#1206073 CVE-2022-49910 bsc#1242452).
- Update
patches.suse/Bluetooth-L2CAP-fix-use-after-free-in-l2cap_conn_del.patch
(CVE-2025-21969 bsc#1240784 CVE-2022-49909 bsc#1242453).
- Update
patches.suse/Bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch
(CVE-2023-1989 bsc#1210336 CVE-2023-53145 bsc#1243047).
- Update patches.suse/SUNRPC-Fix-a-server-shutdown-leak.patch
(git-fixes CVE-2023-53131 bsc#1242377).
- Update
patches.suse/arm64-bpf-Add-BHB-mitigation-to-the-epilogue-for-cBP.patch
(bsc#1242778 CVE-2025-37948 bsc#1243649).
- Update
patches.suse/arm64-bpf-Only-mitigate-cBPF-programs-loaded-by-unpr.patch
(bsc#1242778 CVE-2025-37963 bsc#1243660).
- Update
patches.suse/bpf-sockmap-Fix-the-sk-sk_forward_alloc-warning-of-s.patch
(bsc#1235485 CVE-2024-56633 CVE-2022-49877 bsc#1242483).
- Update
patches.suse/cifs-Fix-connections-leak-when-tlink-setup-failed.patch
(bsc#1190317 CVE-2022-49822 bsc#1242544).
- Update
patches.suse/dm-stats-check-for-and-propagate-alloc_percpu-failur-d3aa.patch
(git-fixes CVE-2023-53044 bsc#1242759).
- Update
patches.suse/ext4-fix-WARNING-in-ext4_update_inline_data.patch
(bsc#1213012 CVE-2023-53100 bsc#1242790).
- Update
patches.suse/ext4-fix-warning-in-ext4_da_release_space.patch
(bsc#1206887 CVE-2022-49880 bsc#1242734).
- Update
patches.suse/ext4-zero-i_disksize-when-initializing-the-bootloade.patch
(bsc#1213013 CVE-2023-53101 bsc#1242791).
- Update
patches.suse/ftrace-Fix-invalid-address-access-in-lookup_rec-when-index-is-0.patch
(git-fixes CVE-2023-53075 bsc#1242218).
- Update
patches.suse/ftrace-Fix-use-after-free-for-dynamic-ftrace_ops.patch
(git-fixes CVE-2022-49892 bsc#1242449).
- Update
patches.suse/gfs2-Check-sb_bsize_shift-after-reading-superblock.patch
(git-fixes CVE-2022-49769 bsc#1242440).
- Update patches.suse/ibmvnic-Free-rwi-on-reset-success.patch
(bsc#1184350 ltc#191533 git-fixes CVE-2022-49906 bsc#1242464).
- Update
patches.suse/igb-revert-rtnl_lock-that-causes-deadlock.patch
(git-fixes CVE-2023-53060 bsc#1242241).
- Update
patches.suse/ila-do-not-generate-empty-messages-in-ila_xlat_nl_cm.patch
(git-fixes CVE-2023-53141 bsc#1242362).
- Update
patches.suse/mISDN-fix-misuse-of-put_device-in-mISDN_register_dev.patch
(CVE-2022-49915 bsc#1242409 CVE-2022-49818 bsc#1242527).
- Update patches.suse/net-iucv-Fix-size-of-interrupt-data.patch
(bsc#1211466 CVE-2023-53108 bsc#1242422).
- Update
patches.suse/net-tunnels-annotate-lockless-accesses-to-dev-needed_headroom.patch
(CVE-2024-26804 bsc#1222629 CVE-2023-53109 bsc#1242405).
- Update
patches.suse/net-usb-lan78xx-Limit-packet-length-to-skb-len.patch
(git-fixes CVE-2023-53068 bsc#1242239).
- Update
patches.suse/net-usb-smsc75xx-Limit-packet-length-to-skb-len.patch
(git-fixes CVE-2023-53125 bsc#1242285).
- Update
patches.suse/net-usb-smsc95xx-Limit-packet-length-to-skb-len.patch
(git-fixes CVE-2023-53062 bsc#1242228).
- Update
patches.suse/net_sched-keep-alloc_hash-updated-after-hash-allocat.patch
(git-fixes CVE-2020-36791 bsc#1242835).
- Update
patches.suse/nfc-pn533-initialize-struct-pn533_out_arg-properly.patch
(CVE-2022-48875 bsc#1229516 CVE-2023-53119 bsc#1242370).
- Update
patches.suse/nfc-st-nci-Fix-use-after-free-bug-in-ndlc_remove-due.patch
(git-fixes bsc#1210337 CVE-2023-1990 CVE-2023-53106
bsc#1242215).
- Update
patches.suse/nfs4-Fix-kmemleak-when-allocate-slot-failed.patch
(git-fixes CVE-2022-49927 bsc#1242416).
- Update
patches.suse/nfsd-decrease-sc_count-directly-if-fail-to-queue-dl_.patch
(CVE-2025-22025 bsc#1241361 CVE-2025-37871 bsc#1242949).
- Update
patches.suse/ring-buffer-Check-for-NULL-cpu_buffer-in-ring_buffer_wake_waiters.patch
(git-fixes CVE-2022-49889 bsc#1242455).
- Update patches.suse/sch_htb-make-htb_deactivate-idempotent.patch
(CVE-2025-37798 bsc#1242414 CVE-2025-37953 bsc#1243543).
- Update
patches.suse/sch_htb-make-htb_qlen_notify-idempotent.patch
(CVE-2025-37798 bsc#1242414 CVE-2025-37932 bsc#1243627).
- Update
patches.suse/scsi-core-Remove-the-proc-scsi-proc_name-directory-earlier.patch
(git-fixes CVE-2023-53140 bsc#1242372).
- Update
patches.suse/scsi-mpt3sas-Fix-NULL-pointer-access-in-mpt3sas_transport_port_add.patch
(git-fixes CVE-2023-53124 bsc#1242165).
- Update
patches.suse/scsi-qla2xxx-Perform-lockless-command-completion-in-.patch
(git-fixes CVE-2023-53041 bsc#1242747).
- Update
patches.suse/scsi-qla2xxx-Synchronize-the-IOCB-count-to-be-in-ord.patch
(bsc#1209292 bsc#1209684 bsc#1209556 CVE-2023-53056
bsc#1242219).
- Update
patches.suse/scsi-scsi_dh_alua-Fix-memleak-for-qdata-in-alua_activate.patch
(git-fixes CVE-2023-53078 bsc#1242231).
- Update
patches.suse/scsi-zfcp-Fix-double-free-of-FSF-request-when-qdio-send-fails
(git-fixes CVE-2022-49789 bsc#1242366).
- Update
patches.suse/tcp-tcp_make_synack-can-be-called-from-process-conte.patch
(git-fixes CVE-2023-53121 bsc#1242225).
- Update
patches.suse/udf-Fix-a-slab-out-of-bounds-write-bug-in-udf_find_e.patch
(bsc#1206649 CVE-2022-49846 bsc#1242716).
- commit 69b5e67
- drm/scheduler: fix fence ref counting (bsc#1242691 CVE-2022-49829)
- commit 14778ea
- net: sched: extract qstats update code into functions
(CVE-2024-26740 bsc#1222563).
- refresh patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
- commit e226feb
- net/sched: act_mirred: use the backlog for mirred ingress
(CVE-2024-26740 bsc#1222563).
- refresh patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
- act_mirred: use the backlog for nested calls to mirred ingress
(CVE-2024-26740 bsc#1222563).
- net/sched: act_mirred: refactor the handle of xmit
(CVE-2024-26740 bsc#1222563).
- cleanup patches.suse/net-smc-Transitional-solution-for-clcsock-race-issue.patch
drop net/sched/act_mirred.c part which was a combination of unrelated
commits which are going to be backported separately now
- refresh patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
- net: sched: don't expose action qstats to skb_tc_reinsert()
(CVE-2024-26740 bsc#1222563).
- net: sched: refactor reinsert action (CVE-2024-26740
bsc#1222563).
- commit 7ca05e8
- can: peak_usb: fix use after free bugs (bsc#1241407
CVE-2021-47670).
- blacklist.conf: blacklisted in error
- commit 3cc9a48
- xenbus: Use kref to track req lifetime (bsc#1243541
CVE-2025-37949).
- commit e59a814
- 9p/net: fix improper handling of bogus negative read/write
replies (bsc#1243077 CVE-2025-37879).
- commit fe1bf4b
- usb: gadget: u_audio: don't let userspace block driver unbind (CVE-2023-53045 bsc#1242756)
- commit 96aa745
- tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header (CVE-2022-49862 bsc#1242755)
- commit d64fec6
- net: macvlan: fix memory leaks of macvlan_common_newlink (CVE-2022-49853 bsc#1242688)
- commit d85ed83
- dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() (CVE-2022-49861 bsc#1242580)
- commit f8dabfc
- ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network (CVE-2022-49865 bsc#1242570)
- commit 8923317
- ata: libata-transport: fix error handling in ata_tport_add() (CVE-2022-49825 bsc#1242548)
- commit e76ffee
- net_sched: sch_sfq: move the limit validation (CVE-2025-37752 bsc#1242504)
- commit 3268e2e
- net_sched: sch_sfq: use a temporary work area for validating configuration (bsc#1232504)
- commit e350897
- net: ena: Fix error handling in ena_init() (CVE-2022-49813 bsc#1242497)
- commit 55f4ea4
- net: mdio: fix undefined behavior in bit shift for __mdiobus_register (CVE-2022-49907 bsc#1242450)
- commit 35b4747
- i40e: Fix kernel crash during reboot when adapter is in recovery mode (CVE-2023-53114 bsc#1242398)
- commit 9232bee
- ALSA: hda: fix potential memleak in 'add_widget_node' (CVE-2022-49835 bsc#1242385)
- commit b245eca
- nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() (CVE-2022-49922 bsc#1242378)
- commit ec5842a
- ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() (CVE-2022-49772 bsc#1242147)
- commit 05dc09a
- Remove debug flavor (bsc#1243919).
This is only released in Leap, and we don't have Leap 42 anymore.
- commit c8f417b
- rpm/check-for-config-changes: add more to IGNORED_CONFIGS_RE
Useful when someone tries (needs) to build the kernel with clang.
- commit 06918e3
- HID: hyperv: fix possible memory leak in mousevsc_probe()
(CVE-2022-49874 bsc#1242478).
- commit 4edbe8d
- Refresh patches.suse/netfilter-nf_tables-Reject-tables-of-unsupported-fam.patch.
Adjusted the backported patch as it caused a regression. bsc#1218752
- commit 9c294ed
- ipv6: Fix signed integer overflow in __ip6_append_data
(CVE-2022-49728 bsc#1239111).
- commit e5a4bfa
- devm-helpers: Add resource managed version of work init (bsc#1242745)
- commit af41987
- pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map() (bsc#1242154)
- commit 28b2ba4
- nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties (CVE-2023-53139 bsc#1242361)
- commit 2977dda
- misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() (CVE-2022-49788 bsc#1242353)
- commit 9e63e91
- mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() (CVE-2022-49787 bsc#1242352)
- commit e6bd23b
- qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info (CVE-2023-53066 bsc#1242227)
- commit 3926868
- pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map (CVE-2022-49832 bsc#1242154)
- commit 18c2436
- HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc (bsc#1242745)
- commit eb37482
- HID: intel-ish-hid: ipc: Fix potential use-after-free in work function (CVE-2023-53039 bsc#1242745)
- commit 09f159d
- workqueue: Add resource managed version of delayed work init (bsc#1242745)
- commit 26c1fec
- sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket
(CVE-2024-53168 bsc#1234887).
- commit 14cbc36
- ACPI: CPPC: Avoid out of bounds access when parsing _CPC data
(CVE-2022-49145 bsc#1238162).
- commit 470a12c
- mtd: phram: Add the kernel lock down check (bsc#1232649).
- commit 9010162
- net/sched: initialize noop_qdisc owner (git-fixes).
- commit 2dfc668
- nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() (CVE-2022-49923 bsc#1242394)
- commit 90c2109
- NFC: nxp-nci: remove unnecessary labels (bsc#1242394)
- commit 211515d
- isofs: Prevent the use of too small fid (CVE-2025-37780 bsc#1242786)
- commit 66b8f1c
- wifi: mac80211: Purge vif txq in ieee80211_do_stop() (CVE-2025-37794 bsc#1242566)
- commit be7520f
- wifi: at76c50x: fix use after free access in at76_disconnect (CVE-2025-37796 bsc#1242727)
- commit 926c6d8
- ext4: fix off-by-one error in do_split (CVE-2025-23150 bsc#1242513)
- commit 63c211a
- d_invalidate(): unhash immediately (bsc#1242140).
- commit 0bb13d9
- net: phy: leds: fix memory leak (CVE-2025-37989 bsc#1243511).
- commit 80b696b
- Refresh fixes for cBPF issue (bsc#1242778)
- Update metadata and put them into the sorted part of the series
- Refresh
patches.suse/x86-bhi-do-not-set-BHI_DIS_S-in-32-bit-mode.patch.
- Refresh
patches.suse/x86-bpf-add-IBHF-call-at-end-of-classic-BPF.patch.
- Refresh
patches.suse/x86-bpf-call-branch-history-clearing-sequence-on-exit.patch.
- commit 78cd843
- kabi: hide owner from struct Qdisc (CVE-2024-27010,
bsc#1223720).
- net/sched: Fix mirred deadlock on device recursion
(CVE-2024-27010, bsc#1223720).
- commit 2646651
- Refresh patches.suse/net-mlx5-Fix-steering-rules-cleanup.patch.
- commit cad4104
- i2c: cros-ec-tunnel: defer probe if parent EC is not present (CVE-2025-37781 bsc#1242575)
- commit 648898d
- nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred (CVE-2022-49729 bsc#1239060)
- commit e4a37ce
- net_sched: skbprio: Remove overly strict queue assertions (CVE-2025-38637 bsc#1241657).
- commit a3f71a8
- usbnet:fix NPE during rx_complete (CVE-2025-22050 bsc#1241441)
- commit b29f445
- thermal: int340x: Add NULL check for adev (CVE-2025-23136 bsc#1241357)
- commit aca813f
- btrfs: do not clean up repair bio if submit fails
(CVE-2022-49168 bsc#1238109).
- commit eb3f122
- ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() (CVE-2023-52988 bsc#1240293)
- commit 47e6e52
- x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL (CVE-2023-52993 bsc#1240297)
- commit b8c925f
- firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region (CVE-2023-52989 bsc#1240266)
- commit 4f68c93
- w1: fix WARNING after calling w1_process() (CVE-2022-49751 bsc#1240254)
- commit 9507421
- nfc: fdp: Fix potential memory leak in fdp_nci_send() (CVE-2022-49924 bsc#1242426)
- commit 1ff0fc5
- PM / devfreq: rk3399_dmc: Disable edev on remove() (CVE-2022-49460 bsc#1238892)
- commit 556bc32
- dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate (CVE-2022-49652 bsc#1238871)
- commit d4f6d8a
- ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix (CVE-2022-49503 bsc#1238868)
- commit b38fbf8
- irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions (CVE-2022-49715 bsc#1238818)
- commit c85152c
- irqchip: gic-v3: Use of_cpu_node_to_id helper (bsc#1238818)
- commit 955125a
- net/mlx5: Fix steering rules cleanup (CVE-2023-53079
bsc#1242765).
- commit 4ab30d6
- ata: libata-transport: fix double ata_host_put() in
ata_tport_add() (CVE-2022-49826 bsc#1242549).
- commit a0074f3
- net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
(CVE-2025-37823 bsc#1242924).
- commit 9b2e245
- team: better TEAM_OPTION_TYPE_STRING validation (CVE-2025-21787 bsc#1238774)
- commit c0334f8
- btrfs: fix inode list leak during backref walking at
resolve_indirect_refs() (CVE-2022-49914 bsc#1242427).
- commit f13d5c5
- thermal: core: prevent potential string overflow (CVE-2023-52868 bsc#1225044)
- commit 45a76bf
- bpf: Prevent bpf program recursion for raw tracepoint probes
(CVE-2022-49764 bsc#1242301).
- commit 193b281
- bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()
(CVE-2022-49840 bsc#1242447).
- commit 19b730c
- nfsd: decrease sc_count directly if fail to queue dl_recall
(CVE-2025-22025 bsc#1241361).
- commit 5566843
- nfsd: put dl_stid if fail to queue dl_recall (CVE-2025-22025
bsc#1241361).
- commit 36e54e4
- pfifo_tail_enqueue: Drop new packet when sch->limit == 0 (CVE-2025-21702 bsc#1237312)
- commit 2cd0611
- usb: cdc-acm: Check control transfer buffer size before access (CVE-2025-21704 bnc#1237571)
- commit 25db018
- ptp: Ensure info->enable callback is always set (CVE-2025-21814 bsc#1238473)
- commit 04ecd88
- net/niu: Niu requires MSIX ENTRY_DATA fields touch before
entry reads (CVE-2025-37833 bsc#1242868).
- PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads
(CVE-2025-37833 bsc#1242868).
- commit 07a4c2c
- drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create() (CVE-2025-37852 bsc#1243074).
- commit 85e74d7
- net: mvpp2: parser fix QinQ (CVE-2025-22060 bsc#1241526).
- Refresh
patches.suse/net-mvpp2-Prevent-parser-TCAM-memory-corruption.patch.
- commit 39cd74b
- nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
(bsc#1235632 CVE-2024-56779).
- commit 6133296
- x86/smpboot: Remove unused phys_id variable (git-commit).
This fixes a build warning.
- commit ceba46a
- kernel/resource: fix kfree() of bootmem memory again
(CVE-2022-49190 bsc#1238130).
- commit 48c0013
- drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() (CVE-2022-49467 bsc#1238815)
- commit 9b240ea
- drm/i915/selftests: fix subtraction overflow bug (CVE-2022-49635 bsc#1238806)
- commit c5c18ff
- net: ppp: Add bound checking for skb data on ppp_sync_txmung (CVE-2025-37749 bsc#1242859)
- commit a8fe412
- netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets (CVE-2025-22063 bsc#1241351)
- commit 69b9c55
- tcp: cdg: allow tcp_cdg_release() to be called multiple times (CVE-2022-49775 bsc#1242245)
- commit 462783c
- rpm: Stop using is_kotd_qa macro
This macro is set by bs-upload-kernel, and a conditional in each spec
file is used to determine when to build the spec file.
This logic should not really be in the spec file. Previously this was
done with package links and package meta for the individula links.
However, the use of package links is rejected for packages in git based
release projects (nothing to do with git actually, new policy). An
alternative to package links is multibuild. However, for multibuild
packages package meta cannot be used to set which spec file gets built.
Use prjcon buildflags instead, and remove this conditional. Depends on
bs-upload-kernel adding the build flag.
- commit 9eb8a6f
- kernel-obs-qa: Use srchash for dependency as well
- commit 485ae1d
- PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type
(CVE-2025-23161 bsc#1242792).
- commit b40664f
- ocfs2: fix the issue with discontiguous allocation in the
global_bitmap (git-fixes).
- commit e15ed3a
- nfsd: fix race between laundromat and free_stateid()
(CVE-2024-50106 bsc#1232882).
- commit a790b42
- dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size
data type (bsc#1238394 CVE-2022-49320).
- commit 436663c
- btrfs: fix inode list leak during backref walking at
find_parent_nodes() (bsc#1242470 CVE-2022-49913).
- commit c05de9e
- btrfs: replace BUG_ON() with error handling at
update_ref_for_cow() (bsc#1230794 CVE-2024-46752).
- commit acac3f6
- Btrfs: don't iterate mod seq list when putting a tree mod seq
(bsc#1242472 CVE-2022-49898).
- btrfs: always pin deleted leaves when there are active tree
mod log users (bsc#1242472 CVE-2022-49898).
- btrfs: fix tree mod log mishandling of reallocated nodes
(bsc#1242472 CVE-2022-49898).
- btrfs: use a bit to track the existence of tree mod log users
(bsc#1242472 CVE-2022-49898).
- btrfs: use the new bit BTRFS_FS_TREE_MOD_LOG_USERS at
btrfs_free_tree_block() (bsc#1242472 CVE-2022-49898).
- Refresh
patches.suse/0002-btrfs-Remove-fsid-metadata_fsid-fields-from-btrfs_in.patch.
- commit dacb815
- memcg_write_event_control(): fix a user-triggerable oops
(CVE-2024-45021 bsc#1230434).
- commit 4e6c9d7
- IB/hfi1: Correctly move list in sc_disable() (CVE-2022-49931 bsc#1242382)
- commit 581a698
- RDMA/core: Fix null-ptr-deref in ib_core_cleanup() (CVE-2022-49925 bsc#1242371)
- commit 629991b
- rtl818x: Prevent using not initialized queues (CVE-2022-49326 bsc#1238646)
- commit 2e4f859
- drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() (CVE-2022-49491 bsc#1238539)
- commit cacfaf7
- driver core: fix deadlock in __device_attach (CVE-2022-49371 bsc#1238546)
- commit e1fc85e
- Refresh patches.suse/tpm-tis-Double-the-timeout-B-to-4s.patch.
- commit db263b9
- Update
patches.suse/USB-usbfs-Don-t-WARN-about-excessively-large-memory-.patch
(bsc#1222004 CVE-2021-47170 CVE-2021-20320).
- commit 2ffa0a7
- Update
patches.suse/sctp-fail-if-no-bound-addresses-can-be-used-for-a-gi.patch
(bsc#1206677 CVE-2023-1074).
- commit 2c70e65
- media: streamzap: fix race between device disconnection and
urb callback (CVE-2025-22027 bsc#1241369).
- commit 45f284f
- ASoC: soc-utils: Remove __exit for snd_soc_util_exit()
(CVE-2022-49842 bsc#1242484).
- commit dfda6bc
- ASoC: core: Fix use-after-free in snd_soc_exit() (CVE-2022-49842
bsc#1242484).
- commit 89ba7b3
- btrfs: always report error in run_one_delayed_ref() (CVE-2022-49761 bsc#1240261)
- commit e432f24
- netfilter: conntrack: clamp maximum hashtable size to INT_MAX (CVE-2025-21648 bsc#1236142)
- commit 9316b29
- media: usb: go7007: s2250-board: fix leak in probe() (CVE-2022-49253 bsc#1238420)
- commit db86595
- sfc: fix kernel panic when creating VF (CVE-2022-49625 bsc#1238411)
- commit bcdf72a
- arm64: insn: Fix two bugs in encoding 32-bit logical immediates
(bsc#1242778).
- commit 538ec8a
- arm64: insn: Add encoder for bitwise operations using literals
(bsc#1242778).
- arm64: insn: Add N immediate encoding (bsc#1242778).
- commit e6408da
- sch_htb: make htb_deactivate() idempotent (CVE-2025-37798
bsc#1242414).
- sch_qfq: make qfq_qlen_notify() idempotent (CVE-2025-37798
bsc#1242414).
- sch_hfsc: make hfsc_qlen_notify() idempotent (CVE-2025-37798
bsc#1242414).
- sch_drr: make drr_qlen_notify() idempotent (CVE-2025-37798
bsc#1242414).
- sch_htb: make htb_qlen_notify() idempotent (CVE-2025-37798
bsc#1242414).
- commit 85d67da
- bonding: Fix memory leak when changing bond type to Ethernet
(CVE-2023-53103 bsc#1242408).
- commit 03cee1f
- bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave
fails (CVE-2023-53103 bsc#1242408).
- bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether
type change (CVE-2023-53103 bsc#1242408).
- commit c76a60e
- Revert "kABI workaround for changeing the variable length type to size_t"
Will evaluate again the CVE and resend the patch if needed
This reverts commit 467381126c46febb6e9adeba40f4439ab1b7f3cd.
- commit 859f819
- Revert "ipv6: Fix signed integer overflow in __ip6_append_data"
Will evaluate again the CVE and resend the patch if needed
This reverts commit 0c4609a89f1351bc34d1fdf73c438d3665a48988.
- commit 9b99659
- Fix cpufeatures kABI
Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit aeb0991
- Refresh
patches.suse/0022-arm64-Use-the-clearbhb-instruction-in-mitigations.patch.
Bring in AARCH64_INSN_HINT_CLEARBHB, which was present in the mainline
patch.
- commit 7ece652
- Bring back 'enum bhb_mitigation_bits' and system_bhb_mitigations
(bsc#1242778)
- Refresh
patches.suse/0019-arm64-Mitigate-spectre-style-branch-history-side-cha.patch.
- Refresh
patches.suse/0022-arm64-Use-the-clearbhb-instruction-in-mitigations.patch.
- commit a6c8f92
- ath9k_htc: fix uninit value bugs (CVE-2022-49235 bsc#1238333)
- commit d0592f5
- drm/tegra: Fix reference leak in tegra_dsi_ganged_probe (CVE-2022-49216 bsc#1238338)
Refresh patches.suse/0001-drm-tegra-dsi-Add-missing-check-for-of_find_device_b.patch.
- commit dff7d50
- mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init (CVE-2022-49212 bsc#1238331)
- commit fd64ee9
- phy: qcom-qmp: fix reset-controller leak on probe errors (CVE-2022-49396 bsc#1238289)
- commit 64c16d6
- arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs
(bsc#1242778).
- commit d71d27e
- arm64: proton-pack: Add new CPUs 'k' values for branch
mitigation (bsc#1242778).
- arm64: bpf: Only mitigate cBPF programs loaded by unprivileged
users (bsc#1242778).
- arm64: proton-pack: Expose whether the branchy loop k value
(bsc#1242778).
- arm64: proton-pack: Expose whether the platform is mitigated
by firmware (bsc#1242778).
- arm64: insn: Add support for encoding DSB (bsc#1242778).
- commit ebb0869
- Refresh
patches.suse/x86-bhi-do-not-set-BHI_DIS_S-in-32-bit-mode.patch.
- Refresh
patches.suse/x86-bpf-add-IBHF-call-at-end-of-classic-BPF.patch.
- Refresh
patches.suse/x86-bpf-call-branch-history-clearing-sequence-on-exit.patch.
Update the patch-mainline header, these patches are expected to be
found upstream at a later date.
- commit 8ba543d
- net: openvswitch: fix nested key length validation in the set()
action (CVE-2025-37789 bsc#1242762).
- commit a168326
- tty: serial: fsl_lpuart: fix race on RX DMA shutdown
(CVE-2023-53094 bsc#1242288).
- commit 053969f
- Update
patches.suse/bpf-Verifer-adjust_scalar_min_max_vals-to-always-call-update_reg_bounds.patch
(bsc#1194227 CVE-2021-4159).
- commit 33266c3
- Update
patches.suse/s390-bpf-Wrap-JIT-macro-parameter-usages-in-parentheses.patch
(bsc#1190601 CVE-2021-20320).
- Update
patches.suse/s390-bpf-fix-64-bit-subtraction-of-the-0x80000000-constant.patch
(bsc#1190601 CVE-2021-20320).
- Update
patches.suse/s390-bpf-fix-branch-shortening-during-codegen-pass.patch
(bsc#1190601 CVE-2021-20320).
- Update
patches.suse/s390-bpf-fix-optimizing-out-zero-extensions.patch
(bsc#1190601 CVE-2021-20320).
- Update
patches.suse/s390-bpf-implement-jitting-of-BPF_ALU-BPF_ARSH-BPF_.patch
(bsc#1190601 CVE-2021-20320).
- commit 3b96b15
- scsi: iscsi_tcp: Fix UAF during logout when accessing the
shost ipaddress (CVE-2023-52975 bsc#1240322).
- scsi: iscsi: Move pool freeing (CVE-2023-52975 bsc#1240322).
- commit d8d45ff
- check-for-config-changes: Fix flag name typo
- commit 1046b16
- netfilter: socket: Lookup orig tuple for IPv6 SNAT
(CVE-2025-22021 bsc#1241282).
- commit 3b93136
- xsk: Add missing overflow check in xdp_umem_reg (CVE-2023-53080
bsc#1242287).
- commit 8b15409
- net_sched: hfsc: Fix a UAF vulnerability in class handling
(CVE-2025-37797 bsc#1242417).
- commit 66a1309
- codel: remove sch->q.qlen check before
qdisc_tree_reduce_backlog() (CVE-2025-37798 bsc#1242414).
- commit 7a9bb75
- hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key
(bsc#1242770 CVE-2025-37782).
- commit 51b3882
- udp: Fix memory accounting leak (CVE-2025-22058 bsc#1241332).
- commit 229f687
- fbdev: hyperv_fb: Simplify hvfb_putmem (git-fixes).
- commit 67adb16
- Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt
(bsc#1238032 CVE-2022-49139).
- commit b38b106
- net: stmmac: fix dma queue left shift overflow issue
(CVE-2022-49592 bsc#1238311).
- commit 1b0d1c7
- Bluetooth: fix dangling sco_conn and use-after-free in
sco_sock_timeout (bsc#1238071 CVE-2022-49474).
- commit 6360cef
- x86/bhi: Do not set BHI_DIS_S in 32-bit mode (bsc#1242778).
- x86/bpf: Add IBHF call at end of classic BPF (bsc#1242778).
- x86/bpf: Call branch history clearing sequence on exit
(bsc#1242778).
- commit 59473c9
- fbdev: hyperv_fb: Allow graceful removal of framebuffer
(git-fixes CVE-2025-21976 bsc#1241145).
- Delete patches.suse/suse-hv-hyperv_fb-rmmod.patch, no longer
needed.
- commit a082a24
- net: gso: fix panic on frag_list with mixed head alloc types
(CVE-2022-49872 bsc#1242594).
- commit 3e759e0
- mISDN: fix possible memory leak in mISDN_dsp_element_register()
(CVE-2022-49821 bsc#1242542).
- commit 22495af
- mISDN: fix misuse of put_device() in mISDN_register_device()
(CVE-2022-49915 bsc#1242409).
- commit 2af5c07
- mISDN: fix possible memory leak in mISDN_register_device()
(CVE-2022-49915 bsc#1242409).
- commit 1096349
- net: tun: call napi_schedule_prep() to ensure we own a napi
(CVE-2022-49871 bsc#1242558).
- net: tun: Fix memory leaks of napi_get_frags (CVE-2022-49871
bsc#1242558).
- macvlan: enforce a consistent minimal mtu (CVE-2022-49776
bsc#1242248).
- commit de7a2f0
- Update
patches.suse/dm-crypt-add-cond_resched-to-dmcrypt_write-fb29.patch
(git-fixes CVE-2023-53051 bsc#1242284).
- commit a2c06ba
- Regression in CVE-2024-56641 fix (CVE-2024-56641, bsc#1235526, bsc#1242319).
- commit a257d42
- soc: rockchip: Fix refcount leak in rockchip_grf_init (CVE-2022-49382 bsc#1238306)
- commit b778a78
- ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction (CVE-2022-49248 bsc#1238284)
- commit 340a548
- tty: fix deadlock caused by calling printk() under tty_port->lock (CVE-2022-49441 bsc#1238263)
- commit 1148c0f
- Refresh patches.suse/suse-hv-hyperv_fb-rmmod.patch.
Fix the following warning:
drivers/video/fbdev/hyperv_fb.c:1363:20: warning: 'hvfb_drv_exit' defined but not used
- commit ce05eff
- audit: Send netlink ACK before setting connection in auditd_set
(bsc#1231450).
- commit f8c00d6
- Update
patches.suse/can-dev-can_get_echo_skb-prevent-call-to-kfree_skb-i.patch
(git-fixes CVE-2020-36789 bsc#1241408).
- Update
patches.suse/can-dev-can_restart-fix-use-after-free-bug.patch
(git-fixes CVE-2021-47668 bsc#1241404).
- Update
patches.suse/can-vxcan-vxcan_xmit-fix-use-after-free-bug.patch
(git-fixes CVE-2021-47669 bsc#1241405).
- Update patches.suse/fou-fix-initialization-of-grc.patch
(CVE-2024-46763 bsc#1230764 CVE-2024-46865 bsc#1231103).
- Update
patches.suse/ndisc-use-RCU-protection-in-ndisc_alloc_skb.patch
(bsc#1239994 CVE-2025-21764 bsc#1237885).
- commit fcb2f6d
- cifs: Fix integer overflow while processing actimeo mount option
(git-fixes).
- commit 0c62491
- cifs: Fix integer overflow while processing acdirmax mount
option (CVE-2025-21963 bsc#1240717).
- commit 6c82fff
- net: annotate races around sk->sk_bound_dev_if (CVE-2022-49420
bsc#1238887).
- commit e87db68
- cifs: Fix integer overflow while processing acregmax mount
option (CVE-2025-21964 bsc#1240740).
- commit 759fa98
- hyperv_fb: disable rmmod (bsc#1241145, CVE-2025-21976).
- commit 001b30c
- drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume (CVE-2022-49489 bsc#1238244)
- commit 70ef453
- drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() (CVE-2022-49232 bsc#1238139)
- commit 233d2c0
- remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region (CVE-2022-49188 bsc#1238138)
- commit 2da2636
- remoteproc: qcom_q6v5_mss: Extract mba/mpss from memory-region (bsc#1238138)
- commit 2730746
- PM: core: keep irq flags in device_pm_check_callbacks() (CVE-2022-49175 bsc#1238099)
- commit ab8e651
- pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources() (CVE-2022-49445 bsc#1238019)
- commit 27189c5
- ibmvnic: Use kernel helpers for hex dumps (CVE-2025-22104 bsc#1241550)
- commit bc8cac0
- kABI workaround for changeing the variable length type to size_t
(CVE-2022-49728 bsc#1239111).
- commit 4673811
- ipv6: Fix signed integer overflow in __ip6_append_data
(CVE-2022-49728 bsc#1239111).
- commit 0c4609a
- igmp: Fix data-races around sysctl_igmp_llm_reports
(CVE-2022-49590 bsc#1238844).
- commit ffcf577
- ipv6: mcast: add RCU protection to mld_newpack() (CVE-2025-21758
bsc#1238737).
- commit ca8335c
- net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels
(CVE-2025-21768 bsc#1238714).
- commit 4d13df3
- atm: Fix NULL pointer dereference (CVE-2025-22018 bsc#1241266)
- commit bc9b2c6
- drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() (CVE-2022-49305 bsc#1238645)
- commit f20b488
- Bluetooth: Fix use after free in hci_send_acl (bsc#1237984
CVE-2022-49111).
- commit 3cd0c1c
- net: mvpp2: Prevent parser TCAM memory corruption
(CVE-2025-22060 bsc#1241526).
- commit 37e999b
- Require zstd in kernel-default-devel when module compression is zstd
To use ksym-provides tool modules need to be uncompressed.
Without zstd at least kernel-default-base does not have provides.
Link: https://github.com/openSUSE/rpm-config-SUSE/pull/82
- commit a3262dd
- Revert "exec: fix the racy usage of fs_struct->in_exec (CVE-2025-22029"
This reverts commit 14a10bfdc080f8fa12291efe393e7af680537978.
This turned out to be not an issue. See https://bugzilla.suse.com/show_bug.cgi?id=1241378#c4
- commit 4a60e73
- net: ibmveth: make veth_pool_store stop hanging (CVE-2025-22053
bsc#1241373).
- commit 4494ff2
- netfilter: IDLETIMER: Fix for possible ABBA deadlock
(CVE-2024-54683 bsc#1235729).
- commit 938d034
- exec: fix the racy usage of fs_struct->in_exec (CVE-2025-22029
bsc#1241378).
- commit 14a10bf
- bfq: Make sure bfqg for which we are queueing requests is online
(bsc#1238307 CVE-2022-49411).
- blacklist.conf: Remove commit from blacklist
- commit 4daae62
- bfq: Track whether bfq_group is still online (bsc#1238307
CVE-2022-49411).
- commit e167d48
- ext4: fix OOB read when checking dotdot dir (bsc#1241640
CVE-2025-37785).
- commit 0093423
- filemap: Fix bounds checking in filemap_read() (bsc#1234209
CVE-2024-50272 bsc#1233461).
- commit e0c4cb2
- fs: relax assertions on failure to encode file handles
(bsc#1236086 CVE-2024-57924).
- commit ee1cce6
- Update references in patches.suse/ext4-fixup-pages-without-buffers.patch
(bsc#1205495 CVE-2022-49171 bsc#1238093).
- commit 3a68ec8
- tpm: Change to kvalloc() in eventlog/acpi.c (CVE-2024-58005 bsc#1237873)
- commit 055cc9d
- nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()
(bsc#1240714 CVE-2025-21927).
- commit 1b9235e
- bpf, selftests: Add verifier test case for imm=0,umin=0,umax=1
scalar (bsc#1238803 CVE-2022-49658).
- commit 76015e8
- bpf: Fix insufficient bounds propagation from
adjust_scalar_min_max_vals (bsc#1238803 CVE-2022-49658).
- commit a84c655
- dlm: prevent NPD when writing a positive value to event_done
(bsc#1241601 CVE-2025-23131).
- commit d96b67e
- PCI/ASPM: Fix link state exit during switch upstream function
removal (CVE-2024-58093 bsc#1241347).
- commit 323974a
- RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow (CVE-2025-22086 bsc#1241458)
- commit 9222451
- drm/amdgpu/cs: make commands with 0 chunks illegal behaviour (CVE-2022-49335 bsc#1238377)
- commit 093b1d6
- drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj (CVE-2022-49137 bsc#1238155)
- commit c883f61
- printk: Fix signed integer overflow when defining
LOG_BUF_LEN_MAX (bsc#1237950 CVE-2024-58017 bsc#1239112).
- commit 7c45b05
- Test the correct macro to detect RT kernel build
Fixes: 470cd1a41502 ("kernel-binary: Support livepatch_rt with merged RT branch")
- commit 50e863e
- fou: fix initialization of grc (CVE-2024-46763 bsc#1230764).
- commit 34d05f5
- kernel-source: Also update the search to match bin/env
Fixes: dc2037cd8f94 ("kernel-source: Also replace bin/env"
- commit bae6b69
- drop_monitor: fix incorrect initialization order (CVE-2025-21862
bsc#1239474).
- net: openvswitch: fix leak of nested actions (CVE-2022-49086
bsc#1238037).
- commit 907826c
- rpm/check-for-config-changes: Add GCC_ASM_FLAG_OUTPUT_BROKEN
Both spellings are actually used
- rpm/check-for-config-changes: Add GCC_ASM_FLAG_OUTPUT_BROKEN
- commit d9e0b30
- fou: Fix null-ptr-deref in GRO (CVE-2024-46763 bsc#1230764).
- commit 87825b6
- net: fix geneve_opt length integer overflow (CVE-2025-22055
bsc#1241371).
- commit 7a515dd
- hwpoison, memory_hotplug: lock folio before unmap hwpoisoned
folio (CVE-2025-21931 bsc#1240709).
- commit 4b52623
- skbuff: introduce skb_pull_data (bsc#1235038 CVE-2024-56590).
- commit 4f3bce2
- rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy
(CVE-2025-21635 bsc#1236111).
- commit 30122f9
- Bluetooth: hci_core: Fix not checking skb length on
hci_acldata_packet (bsc#1235038 CVE-2024-56590).
- commit 2b46315
- partitions: mac: fix handling of bogus partition table
(CVE-2025-21772 bsc#1238911).
- scsi: lpfc: Resolve NULL ptr dereference after an ELS LOGO is
aborted (CVE-2022-49730 bsc#1239070).
- scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp()
(CVE-2022-49521 bsc#1238938).
- scsi: lpfc: Fix call trace observed during I/O with CMF enabled
(CVE-2022-49537 bsc#1238930).
- scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT
(CVE-2022-49534 bsc#1238893).
- scsi: lpfc: Fix null pointer dereference after failing to
issue FLOGI and PLOGI (CVE-2022-49535 bsc#1238937).
- commit 9071ce6
- scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock
(CVE-2022-49536 bsc#1238838).
- Refresh
patches.suse/scsi-lpfc-Validate-hdwq-pointers-before-dereferencin.patch.
- commit 1f1a811
- block, bfq: don't move oom_bfqq (CVE-2022-49179 bsc#1238092).
- commit 08606de
- drivers/base/node.c: fix compaction sysfs file leak (CVE-2022-49442 bsc#1238243)
- commit 769486d
- dmaengine: Fix double increment of client_count in dma_chan_get() (CVE-2022-49753 bsc#1240250)
- commit 8be64a3
- tcp: add accessors to read/set tp->snd_cwnd (CVE-2022-49325
bsc#1238398).
- Refresh
patches.suse/tcp-fix-tcp_mtup_probe_success-vs-wrong-snd_cwnd.patch.
- commit 00d8ac0
- rpm/kernel-binary.spec.in: Also order against update-bootloader
(boo#1228659, boo#1240785, boo#1241038).
- commit fe0a8c9
- net: altera: Fix refcount leak in altera_tse_mdio_create
(CVE-2022-49351 bsc#1237939).
- commit 3aeeb63
- rpm/package-descriptions: Add rt and rt_debug descriptions
- commit 09573c0
- mac80211: fix potential double free on mesh join (CVE-2022-49290 bsc#1238156)
- commit 1243bb0
- wifi: rtlwifi: fix memory leaks and invalid access at probe error path (CVE-2024-58063 bsc#1238984)
- commit fac1ba9
- wifi: brcmfmac: Check the return value of of_property_read_string_index() (CVE-2025-21750 bsc#1238905)
- commit f37f3e1
- wifi: brcmfmac: use strreplace() in brcmf_of_probe() (bsc#1238905)
- commit af07444
- brcmfmac: of: remove redundant variable len (bsc#1238905)
- commit 990953e
- brcmfmac: of: Use devm_kstrdup for board_type & check for errors (bsc#1238905)
- commit d9e8c8a
- net: nfc: Fix use-after-free in local_cleanup() (CVE-2023-53023 bsc#1240309)
- commit f91c2a0
- i40e: Fix call trace in setup_tx_descriptors (CVE-2022-49725 bsc#1238016)
- commit 4f6a558
- net: gso: fix ownership in __udp_gso_segment (CVE-2025-21926
bsc#1240712).
- commit 112bb59
- wifi: cfg80211: regulatory: improve invalid hints checking
(CVE-2025-21910 bsc#1240583).
- commit 2ad169d
- wifi: nl80211: reject cooked mode if it is set along with
other flags (CVE-2025-21909 bsc#1240590).
- commit b2acee6
- net: atm: fix use after free in lec_send() (CVE-2025-22004
bsc#1240835).
- commit cc63f73
- drm/plane: Move range check for format_count earlier (CVE-2021-47659 bsc#1237839)
- commit cc111ee
- dm integrity: fix memory corruption when tag_size is less than digest size (CVE-2022-49044 bsc#1237840)
- commit be90f4e
- net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() (CVE-2022-49060 bsc#1237845)
- commit 867ee3a
- drm/amdkfd: Check for potential null return of kmalloc_array() (CVE-2022-49055 bsc#1237868)
- commit afbd83d
- driver: base: fix UAF when driver_attach failed (CVE-2022-49385 bsc#1237951)
- commit 3dcc3aa
- drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf (CVE-2022-49693 bsc#1237954)
- commit d40fafb
- PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events (CVE-2022-49668 bsc#1237957)
- commit fff3251
- media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init (CVE-2022-49478 bsc#1238000)
- commit 5c8c17f
- media: cx25821: Fix the warning when removing the module (CVE-2022-49525 bsc#1238022)
- commit 8b2ba54
- scsi: lpfc: Move cfg_log_verbose check before calling
lpfc_dmp_dbg() (CVE-2022-49542 bsc#1238722).
- commit 2fbb1a4
- scsi: pm8001: Fix tag leaks on error (CVE-2022-49121
bsc#1237926).
- Refresh
patches.suse/scsi-pm8001-Fix-memory-leak-in-pm8001_chip_fw_flash_.patch.
- commit 1183fb2
- block: fix integer overflow in BLKSECDISCARD (CVE-2024-49994
bsc#1237757).
- scsi: lpfc: Inhibit aborts if external loopback plug is inserted
(CVE-2022-49504 bsc#1238835).
- scsi: hisi_sas: Free irq vectors in order for v3 HW
(CVE-2022-49118 bsc#1237979).
- bfq: fix use-after-free in bfq_dispatch_request (CVE-2022-49176
bsc#1238097).
- commit 61a23eb
- Refresh
patches.suse/net-usb-usbnet-restore-usb-d-name-exception-for-loca.patch.
Patch has been accepted upstream. Moving to correct section.
- commit 44e2f7a
- drm/amd/display: Assign normalized_pix_clk when color depth = 14 (bsc#1240739 CVE-2025-21956)
- commit 8258112
- regulator: check that dummy regulator has been probed before
using it (CVE-2025-22008 bsc#1240942).
- commit e222593
- drm/amd/display: Fix null check for pipe_ctx->plane_state in (bsc#1240701 CVE-2025-21941)
- commit 4fd9018
- blk-throttle: Set BIO_THROTTLED when bio has been throttled
(CVE-2022-49465 bsc#1238919).
- commit 885f88f
- usb: xhci: Fix NULL pointer dereference on certain command aborts (CVE-2024-57981 bsc#1237912)
- commit a6014fc
- media: uvcvideo: Fix double free in error path (CVE-2024-57980 bsc#1237911)
- commit c75a886
- NFC: nci: Add bounds checking in nci_hci_create_pipe() (CVE-2025-21735 bsc#1238497)
- commit 1703ca8
- drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit() (CVE-2024-52559 bsc#1238507)
- commit 151c011
- Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc (CVE-2024-58009 bsc#1238760)
- commit f77505b
- KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel (CVE-2025-21779 bsc#1238768)
- commit c0bacb1
- netfilter: xtables: fix typo causing some targets not to load
on IPv6 (CVE-2024-50038 bsc#1231910).
- netfilter: xtables: avoid NFPROTO_UNSPEC where needed
(CVE-2024-50038 bsc#1231910).
- commit 758059b
- rpm/check-for-config-changes: add LD_CAN_ to IGNORED_CONFIGS_RE
We now have LD_CAN_USE_KEEP_IN_OVERLAY since commit:
e7607f7d6d81 ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE
- commit 7b55ff2
- RDMA/hns: Fix soft lockup during bt pages loop (CVE-2025-22010 bsc#1240943)
- commit 4f43f30
- rpm/kernel-binary.spec.in: Use OrderWithRequires (boo#1228659 boo#1241038).
OrderWithRequires was introduced in rpm 4.9 (ie. SLE12+) to allow
a package to inform the order of installation of other package without
hard requiring that package. This means our kernel-binary packages no
longer need to hard require perl-Bootloader or dracut, resolving the
long-commented issue there. This is also needed for udev & systemd-boot
to ensure those packages are installed before being called by dracut
(boo#1228659)
- commit 634be2c
- i2c: designware: use casting of u64 in clock multiplication to avoid overflow (CVE-2022-49749 bsc#1240243)
- commit 8e8de37
- HID: appleir: Fix potential NULL dereference at raw event handle (CVE-2025-21948 bsc#1240703)
- commit 00a5124
- scsi: qla1280: Fix kernel oops when debug level > 2 (CVE-2025-21957 bsc#1240742)
- commit bd23d83
- net: let net.core.dev_weight always be non-zero (CVE-2025-21806 bsc#1238746)
- commit f158377
- net: Fix data-races around weight_p and dev_weight_[rt]x_bias (bsc#1238746)
- commit f948447
- Bluetooth: L2CAP: Fix build errors in some archs (CVE-2025-21969
bsc#1240784).
- commit 7b7dc2b
- Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()
(CVE-2025-21969 bsc#1240784).
- Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression
(CVE-2025-21969 bsc#1240784).
- commit 45ad638
- kABI workaround for l2cap_conn changes (CVE-2025-21969
bsc#1240784).
- commit 7316449
- Bluetooth: L2CAP: Fix corrupted list in hci_chan_del
(CVE-2025-21969 bsc#1240784).
- Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put
(CVE-2025-21969 bsc#1240784).
- commit afacee7
- Bluetooth: Fix error code in chan_alloc_skb_cb() (bsc#1240582
CVE-2025-22007).
- commit b580f9e
- drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse() (CVE-2025-21996 bsc#1240801).
- commit 4ea5dea
- usb: atm: cxacru: fix a flaw in existing endpoint checks
(bsc#1240582 CVE-2025-21916).
- commit e17a34b
- Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd
(CVE-2025-21969 bsc#1240784).
- commit 900222a
- iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in
ibft_attr_show_nic() (CVE-2025-21993 bsc#1240797).
- commit 1c1b4a4
- kernel-binary: Support livepatch_rt with merged RT branch
- commit 470cd1a
- tpm: tis: Double the timeout B to 4s (bsc#1235870).
- commit e4e19da
- tpm, tpm_tis: Workaround failed command reception on Infineon
devices (bsc#1235870).
- commit 87601ca
- ppp: Fix KMSAN uninit-value warning with bpf (CVE-2025-21922
bsc#1240639).
- commit ca66710
- arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array (CVE-2025-21785 bsc#1238747)
- commit 24fbd3b
- rapidio: add check for rio_add_net() in rio_scan_alloc_net()
(CVE-2025-21935 bsc#1240700).
- rapidio: fix an API misues when rio_add_net() fails
(CVE-2025-21934 bsc#1240708).
- commit df62006
- macsec: fix UAF bug for real_dev (CVE-2022-49390 bsc#1238233)
- commit d0ae16a
- dax: make sure inodes are flushed before destroy cache (CVE-2022-49220 bsc#1237936)
- commit dd8bb0a
- sysctl: Fix data races in proc_douintvec() (CVE-2022-49641 bsc#1237831)
- commit 1859db6
- gpu: host1x: Fix a memory leak in 'host1x_remove()' (CVE-2021-47648 bsc#1237725)
- commit 565f8ec
- qede: confirm skb is allocated before using (CVE-2022-49084 bsc#1237751)
- commit a2a6334
- rpm/check-for-config-changes: ignore DRM_MSM_VALIDATE_XML
This option is dynamically enabled to build-test different configurations.
This makes run_oldconfig.sh complain sporadically for arm64.
- commit 8fbe8b1
- net: fix data-races around sk->sk_forward_alloc (CVE-2024-53124
bsc#1234074).
- commit 7d9d482
- netfilter: conntrack: re-fetch conntrack after insertion
(CVE-2022-49561 bsc#1238537).
- commit d3e0ad2
- netfilter: ipset: Fix overflow before widen in the
bitmap_ip_create() function (CVE-2023-53032 bsc#1240270).
- commit 7dde838
- ipv4: prevent potential spectre v1 gadget in
ip_metrics_convert() (CVE-2023-52997 bsc#1240303).
- commit ed98686
- sysctl: Fix data races in proc_douintvec_minmax() (CVE-2022-49640 bsc#1237782)
- commit 0dfbf72
- kernel/sysctl.c: define minmax conv functions in terms of non-minmax versions (bsc#1237782)
- commit 1263b48
- Update references for patches.suse/kernel-sysctl.c-add-missing-range-check-in-do_proc_d.patch (bsc#1237782 bsc#1051510)
- commit 51d8dd8
- pipe: reject F_SETPIPE_SZ with size over UINT_MAX (bsc#1237782)
- commit 57c3c8a
- pipe, sysctl: remove pipe_proc_fn() (bsc#1237782)
- commit 5b47dc3
- pipe, sysctl: drop 'min' parameter from pipe-max-size converter (bsc#1237782)
- commit 559c162
- sysctl: check for UINT_MAX before unsigned int min/max (bsc#1237782)
- commit 6169ace
- pipe: add proc_dopipe_max_size() to safely assign pipe_max_size (bsc#1237782)
- commit 2f6a8d2
- Update references for patches.suse/pipe-match-pipe_max_size-data-type-with-procfs.patch (bsc#1237782 git-fixes)
- commit 4bc1ec0
- nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling (CVE-2022-49331 bsc#1237813)
- commit 8331408
- phy: qcom-qmp: fix struct clk leak on probe errors (CVE-2022-49397 bsc#1237823)
- commit 29ed697
- KVM: VMX: Prevent RSB underflow before vmenter (CVE-2022-49610
bsc#1238952).
- commit bea6096
- x86/kexec: Fix double-free of elf header buffer (git-fixes
CVE-2022-49546 bsc#1238750).
- x86/kexec: fix memory leak of elf header buffer (CVE-2022-49546
bsc#1238750).
- commit 69722e9
- Refresh patches.suse/ipv6-icmp-convert-to-dev_net_rcu.patch.
- commit 8cd0e69
- bpf, sockmap: Fix double uncharge the mem of sk_msg
(CVE-2022-49205 bsc#1238335).
- commit f6c5311
- af_netlink: Fix shift out of bounds in group mask calculation
(CVE-2022-49197 bsc#1238455).
- commit 9a4a535
- uprobes: Reject the shared zeropage in uprobe_write_opcode() (CVE-2025-21881 bsc#1240185)
- commit f4218b4
- firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle (bsc#1238467)
- commit 1cd86ca
- rpm/release-projects: Update the ALP projects again (bsc#1231293).
- commit a2f9145
- scsi: target: tcmu: Fix possible page UAF (CVE-2022-49053
bsc#1237918).
- commit beef048
- mm/khugepaged: fix ->anon_vma race (CVE-2023-52935 bsc#1240276).
- commit a534f8f
- usbnet: gl620a: fix endpoint checking in genelink_bind()
(bsc#1240172 CVE-2025-21877).
- commit 4ca0b45
- Refresh
patches.suse/ipv4-use-RCU-protection-in-ip_dst_mtu_maybe_forward.patch.
- commit 22f6eba
- netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()
(git-fixes CVE-2025-21703 bsc#1237313).
- commit cbd2039
- net: sfp: fix memory leak in sfp_probe() (CVE-2022-49619 bsc#1239003)
- commit 04c9c14
- net: tipc: fix possible refcount leak in tipc_sk_create() (CVE-2022-49620 bsc#1239002)
- commit 73f1781
- team: prevent adding a device which is already a team device lower (CVE-2024-58071 bsc#1238970
- commit 850cca8
- tcp: tcp_rtx_synack() can be called from process context
(CVE-2022-49372 bsc#1238251).
- commit 2b7ccd1
- af_unix: Fix a data-race in unix_dgram_peer_wake_me()
(CVE-2022-49344 bsc#1237988).
- commit 906cfb9
- net/sched: netem: account for backlog updates from child qdisc
(CVE-2024-56770 bsc#1235637).
- net/smc: fix LGR and link use-after-free issue (CVE-2024-56640
bsc#1235436).
- netlink: terminate outstanding dump on socket close
(CVE-2024-53140 bsc#1234222).
- commit fa3efff
- net: mana: Support holes in device list reply msg (bsc#1240133).
- ipvlan: ensure network headers are in skb linear part
(CVE-2025-21891 bsc#1240186).
- bnxt: Do not read past the end of test names (CVE-2023-53010
bsc#1240290).
- net: mdio: validate parameter addr in mdiobus_get_phy()
(CVE-2023-53019 bsc#1240286).
- commit 44816a5
- wifi: brcmfmac: Check the count value of channel spec to
prevent out-of-bounds reads (CVE-2022-49740 bsc#1240233).
- commit 0c49112
- Update
patches.suse/ibmvnic-Don-t-reference-skb-after-sending-to-VIOS.patch
(CVE-2025-21858 bsc#1239468 CVE-2025-21855 bsc#1239484).
- commit f98b7e1
- Update
patches.suse/media-cx24116-prevent-overflows-on-SNR-calculus.patch
(CVE-2024-50290 bsc#1233479 bsc#1225742).
- Update
patches.suse/media-dvbdev-prevent-the-risk-of-out-of-memory-acces.patch
(CVE-2024-53063 bsc#1233557 bsc#1225742).
- commit 3bb8dac
- Update
patches.suse/HID-betop-check-shape-of-output-reports.patch
(git-fixes bsc#1207186 CVE-2023-53015 bsc#1240288).
- Update
patches.suse/Squashfs-fix-handling-and-sanity-checking-of-xattr_i.patch
(git-fixes CVE-2023-52933 bsc#1240275).
- Update
patches.suse/bpf-Fix-pointer-leak-due-to-insufficient-speculative.patch
(bsc#1231375 CVE-2023-53024 bsc#1240272).
- Update
patches.suse/cifs-Fix-oops-due-to-uncleared-server-smbd_conn-in-reconnect.patch
(bsc#1190317 CVE-2023-53006 bsc#1240208).
- Update
patches.suse/cifs-fix-potential-memory-leaks-in-session-setup.patch
(bsc#1190317 CVE-2023-53008 bsc#1240318).
- Update
patches.suse/netlink-prevent-potential-spectre-v1-gadgets.patch
(bsc#1209547 CVE-2017-5753 CVE-2023-53000 bsc#1240227).
- Update
patches.suse/powerpc-imc-pmu-Fix-use-of-mutex-in-IRQs-disabled-se.patch
(bsc#1054914 fate#322448 git-fixes CVE-2023-53031 bsc#1240285).
- Update
patches.suse/scsi-iscsi_tcp-Fix-UAF-during-login-when-accessing-the-shost-ipaddress.patch
(bsc#1210647 CVE-2023-2162 CVE-2023-52974 bsc#1240213).
- Update
patches.suse/squashfs-harden-sanity-check-in-squashfs_read_xattr_.patch
(git-fixes CVE-2023-52979 bsc#1240282).
- Update
patches.suse/tracing-Make-sure-trace_printk-can-output-as-soon-as-it-can-be-used.patch
(git-fixes CVE-2023-53007 bsc#1240229).
- Update
patches.suse/vc_screen-move-load-of-struct-vc_data-pointer-in-vcs.patch
(bsc#1213167 CVE-2023-3567 CVE-2023-52973 bsc#1240218).
- commit 5c75cc8
- Update
patches.suse/cpufreq-governor-Use-kobject-release-method-to-free-dbs_data.patch
(bsc#1237800 CVE-2022-49513).
- commit d961554
- um: Fix out-of-bounds read in LDT setup (CVE-2022-49395 bsc#1237953)
- commit 9b1534c
- firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle (CVE-2022-49370 bsc#1238467)
- commit 56fb9f5
- ipw2x00: Fix potential NULL dereference in libipw_xmit() (CVE-2022-49544 bsc#1238721)
- commit b1c6aa1
- tee: optee: Fix supplicant wait loop (CVE-2025-21871
bsc#1240183).
- commit dd819c0
- team: add ethtool get_link_ksettings (bsc#1228909).
- commit 29a7164
- Refresh
patches.suse/net-remove-two-BUG-from-skb_checksum_help.patch.
- commit f154628
- cpufreq: governor: Use kobject release() method to free dbs_data
(bsc#1237800).
- dbs_data kABI workaround (bsc#1237800 CVE-2022-49513).
- commit 1891c97
- cpufreq: Move to_gov_attr_set() to cpufreq.h (bsc#1237800
CVE-2022-49513).
- commit af55b29
- net: usb: usbnet: restore usb%d name exception for local mac
addresses (bsc#1234480).
- commit c9b9e0d
- scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req() (CVE-2022-49119 bsc#1237925)
- commit 3b2e4a3
- scsi: pm8001: Fix task leak in pm8001_send_abort_all() (CVE-2022-49120 bsc#1237969)
- commit 5941b1a
- RDMA/hfi1: Prevent use of lock before it is initialized (CVE-2022-49433 bsc#1238268)
- commit 6b108b0
- drm/msm/hdmi: check return value after calling
platform_get_resource_byname() (CVE-2022-49495 bsc#1237932).
- commit 250e248
- ipv6: mcast: extend RCU protection in igmp6_send()
(CVE-2025-21759 bsc#1238738).
- commit de67669
- ndisc: extend RCU protection in ndisc_send_skb() (CVE-2025-21760
bsc#1238763).
- commit bbd5bed
- vrf: use RCU protection in l3mdev_l3_out() (CVE-2025-21791
bsc#1238512).
- commit 67aac47
- arp: use RCU protection in arp_xmit() (CVE-2025-21762
bsc#1238780).
- commit 86c524f
- neighbour: use RCU protection in __neigh_notify()
(CVE-2025-21763 bsc#1237897).
- commit d195b5b
- ndisc: use RCU protection in ndisc_alloc_skb() (bsc#1239994).
- commit f3d8410
- ndisc: ndisc_send_redirect() must use dev_get_by_index_rcu()
(bsc#1239994).
- commit 794c7eb
- ipv6: Use RCU in ip6_input() (bsc#1239994).
- commit 81adbde
- ipv6: icmp: convert to dev_net_rcu() (bsc#1239994).
- commit 86dda00
- ipv6: use RCU protection in ip6_default_advmss() (CVE-2025-21765
bsc#1237906).
- commit 00b5f63
- ipv4: use RCU protection in __ip_rt_update_pmtu()
(CVE-2025-21766 bsc#1238754).
- commit ae267d9
- ipv4: use RCU protection in inet_select_addr() (bsc#1239994).
- commit 442e2c4
- ipv4: use RCU protection in rt_is_expired() (bsc#1239994).
- commit 6439cd7
- ipv4: use RCU protection in ip_dst_mtu_maybe_forward()
(bsc#1239994).
- commit 6b0f168
- ipv4: add RCU protection to ip4_dst_hoplimit() (bsc#1239994).
- commit fc7ba98
- net: add dev_net_rcu() helper (bsc#1239994).
- commit 51827b8
- net: treat possible_net_t net pointer as an RCU one and add
read_pnet_rcu() (bsc#1239994).
- commit a3369f3
- drm/amdgpu: Fix potential NULL pointer dereference in
atomctrl_get_smc_sclk_range_table (CVE-2024-58052 bsc#1238986).
- commit 9320da0
- rpm/kernel-binary.spec.in: Fix missing 20-kernel-default-extra.conf (bsc#1239986)
sle_version was obsoleted for SLE16. It has to be combined with
suse_version check.
- commit cbd5de3
- KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
(CVE-2024-58083 bsc#1239036).
- commit 22cf047
- nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() (CVE-2025-21848
bsc#1239479).
- commit 55016a1
- igc: Reinstate IGC_REMOVED logic and implement it properly
(CVE-2022-49605 bsc#1238433).
- commit 5af1e50
- net: dsa: mv88e6xxx: Fix refcount leak in
mv88e6xxx_mdios_register (CVE-2022-49367 bsc#1238447).
- commit 3ebb662
- net: tun: unlink NAPI from device on destruction (CVE-2022-49672
bsc#1238816).
- commit e432fa1
- kABI fix for tcp: properly terminate timers for kernel sockets
(CVE-2024-35910 bsc#1224489).
- commit 03a709f
- ip: Fix data-races around sysctl_ip_prot_sock. (CVE-2022-49578 bsc#1238794)
- commit 55c2c0e
- kABI fix for mptcp: add sk_stop_timer_sync helper
(CVE-2024-35910 bsc#1224489).
- commit d3152b9
- mptcp: add sk_stop_timer_sync helper (CVE-2024-35910
bsc#1224489).
- Refresh patches.suse/net-add-sock_init_data_uid.patch.
- commit b72feae
- net: remove two BUG() from skb_checksum_help() (CVE-2022-49497
bsc#1238946).
- commit 243b7fc
- net: bonding: fix use-after-free after 802.3ad slave unbind (CVE-2022-49667 bsc#1238282)
- commit bd21be6
- wifi: mac80211: fix use-after-free in chanctx code (CVE-2022-49416 bsc#1238293)
- commit 40d129d
- bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove() (CVE-2022-49711 bsc#1238416)
- commit 1048344
- media: pci: cx23885: Fix the error handling in cx23885_initdev() (CVE-2022-49524 bsc#1238949)
- commit 45001c2
- NFC: NULL out the dev->rfkill to prevent UAF (CVE-2022-49505 bsc#1238615)
- commit 8dd4c4d
- kABI: protect mr_ifc_count change (CVE-2022-49589 bsc#1238598).
- igmp: Fix data-races around sysctl_igmp_qrv (CVE-2022-49589
bsc#1238598).
- net: igmp: increase size of mr_ifc_count (CVE-2022-49589
bsc#1238598).
- net: igmp: fix data-race in igmp_ifc_timer_expire()
(CVE-2022-49589 bsc#1238598).
- commit 3efb324
- i2c: dev: check return value when calling dev_set_name() (CVE-2022-49046 bsc#1237842)
- commit de84566
- btrfs: fix qgroup reserve overflow the qgroup limit
(CVE-2022-49075 bsc#1237733).
- commit bf9031a
- ceph: fix inode reference leakage in ceph_get_snapdir() (CVE-2022-49109 bsc#1237836)
- commit d418afc
- ceph: fix up error handling with snapdirs (bsc#1237836)
- commit f7001b0
- ubi: ubi_create_volume: Fix use-after-free when volume creation failed (CVE-2022-49388 bsc#1237934)
- commit 0d5c203
- ceph: fix memory leak in ceph_readdir when note_last_dentry returns error (CVE-2022-49107 bsc#1237973)
- commit 40beec1
- ila: serialize calls to nf_register_net_hooks() (CVE-2024-57900
bsc#1235973).
- commit d69423e
- tcp: properly terminate timers for kernel sockets
(CVE-2024-35910 bsc#1224489).
- commit 5ce5df8
- ACPI: PAD: fix crash in exit_round_robin() (bsc#1232370
CVE-2024-49935).
- commit e03632e
- Update
patches.suse/netfilter-nf_tables-initialize-registers-in-nft_do_c.patch
(CVE-2022-1016 bsc#1197227 CVE-2022-49293 bsc#1239454).
- commit cedf6cd
- fbdev: omap: use threaded IRQ for LCD DMA (bsc#1239174 CVE-2025-21821)
- commit f159c1f
- drm/amd/pm: fix double free in si_parse_power_table() (bsc#1238944 CVE-2022-49530)
- commit dfebfa5
- net: phy: micrel: Allow probing without .driver_data
(CVE-2022-49472 bsc#1238951).
- ice: always check VF VSI pointer values (CVE-2022-49516
bsc#1238953).
- commit f9c1961
- geneve: Suppress list corruption splat in
geneve_destroy_tunnels() (CVE-2025-21858 bsc#1239468).
- gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl()
(CVE-2025-21865 bsc#1239481).
- ibmvnic: Don't reference skb after sending to VIOS
(CVE-2025-21858 bsc#1239468).
- geneve: Fix use-after-free in geneve_find_dev() (CVE-2025-21858
bsc#1239468).
- commit 7c11337
- net: fix SO_REUSEPORT return code (bsc#1239448)
- commit 3c526b1
- nfsd: clear acl_access/acl_default after releasing them
(bsc#1238716 CVE-2025-21796).
- commit d1c11c1
- acct: perform last write from workqueue (CVE-2025-21846
bsc#1239508).
- commit 5fc1617
- irqchip/gic-v3: Fix GICR_CTLR.RWP polling (git-fixes
CVE-2022-49074 bsc#1237728).
- commit 9f6dc13
- media: staging: media: zoran: calculate the right buffer number
for zoran_reap_stat_com (CVE-2021-47645 bsc#1237767).
- commit eab4973
- PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1
(CVE-2025-21831 bsc#1239039).
- commit 10f73c4
- net/smc: check iparea_offset and ipv6_prefixes_cnt when
receiving proposal msg (CVE-2024-49571 bsc#1235733).
- commit ef9a771
- kABI fix for l2tp: prevent possible tunnel refcount underflow
(CVE-2024-49940 bsc#1232812).
Upstream commit 24256415d186 ("l2tp: prevent possible tunnel
refcount underflow") changed the API of `l2tp_session_set_header_len()`
and this patch re-introduces the API in that version.
- commit 803eb4b
- l2tp: prevent possible tunnel refcount underflow (CVE-2024-49940
bsc#1232812).
- commit 377601f
- drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock (bsc#1238600 CVE-2022-49488)
- commit b961f00
- bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is
full (bsc#1238252 CVE-2022-49209).
- commit aeb9c23
- scripts: fix incorrect regex escape
With Tumbleweed's recent switch to Python 3.13 recently I noticed
several syntax warning related to regex
.../scripts/python/suse_git/patch.py:57: SyntaxWarning: invalid escape sequence '\*'
break_matcher = re.compile(b"(---|\*\*\*|Index:)[ \t][^ \t]|^diff -")
.../scripts/python/git_sort/git_sort.py:490: SyntaxWarning: invalid escape sequence '\.'
version_match = re.compile("refs/tags/v(2\.6\.\d+|\d\.\d+)(-rc\d+)?$")
.../scripts/python/git_sort/git_sort.py:578: SyntaxWarning: invalid escape sequence '\.'
m = re.search("v([0-9]+)\.([0-9]+)(|-rc([0-9]+))$", tags[-1])
Fix them by using raw string/byte literal instead.
Link: https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
- commit 74871be
- netpoll: Fix race condition in netpoll_owner_active
(CVE-2024-41005 bsc#1227858).
- net: make sure napi_list is safe for RCU traversal
(CVE-2024-41005 bsc#1227858).
- commit b55492f
- net: usb: aqc111: Fix out-of-bounds accesses in RX fixup
(bsc#1237903 CVE-2022-49051).
- commit eb6ef6f
- usb: musb: sunxi: Fix accessing an released usb phy (bsc#1233458
CVE-2024-50269).
- commit 14a906c
- USB: hub: Ignore non-compliant devices with too many configs
or interfaces (bsc#1238909 CVE-2025-21776).
- commit 6d1cc77
- net: usb: rtl8150: enable basic endpoint checking (bsc#1239087
CVE-2025-21708).
- commit 582b035
- Refresh
patches.suse/net-smc-fix-kernel-panic-caused-by-race-of-smc_sock.patch.
- commit 89c4c51
- ALSA: usb-audio: Cancel pending work at closing a MIDI substream
(CVE-2022-49545 bsc#1238729).
- commit c5aef00
- net_sched: sch_sfq: don't allow 1 packet limit (CVE-2024-57996
bsc#1239076).
- commit 30f09ff
- wifi: brcmfmac: fix NULL pointer dereference in
brcmf_txfinalize() (CVE-2025-21744 bsc#1238903).
- commit af88382
- Update
patches.suse/0006-dm-raid-fix-accesses-beyond-end-of-raid-member-array.patch
(git-fixes CVE-2022-49674 bsc#1239041).
- Update
patches.suse/0013-block-don-t-delete-queue-kobject-before-its-children.patch
(git-fixes CVE-2022-49259 bsc#1238413).
- Update
patches.suse/0013-dm-mirror-log-round-up-region-bitmap-size-to-BITS_PE.patch
(git-fixes CVE-2022-49710 bsc#1238417).
- Update
patches.suse/0015-bfq-Update-cgroup-information-before-merging-bio.patch
(git-fixes CVE-2022-49413 bsc#1238710).
- Update
patches.suse/0074-dm-ioctl-prevent-potential-spectre-v1-gadget.patch
(git-fixes CVE-2022-49122 bsc#1237983).
- Update
patches.suse/0077-nbd-call-genl_unregister_family-first-in-nbd_cleanup.patch
(git-fixes CVE-2022-49295 bsc#1238707).
- Update
patches.suse/0078-nbd-fix-race-between-nbd_alloc_config-and-module-removal.patch
(git-fixes CVE-2022-49300 bsc#1238183).
- Update
patches.suse/0079-nbd-fix-io-hung-while-disconnecting-device.patch
(git-fixes CVE-2022-49297 bsc#1238469).
- Update
patches.suse/ALSA-pcm-Fix-potential-AB-BA-lock-with-buffer_mutex-.patch
(CVE-2022-1048 bsc#1197331 CVE-2022-49272 bsc#1238272).
- Update
patches.suse/ALSA-pcm-Fix-races-among-concurrent-hw_params-and-hw.patch
(CVE-2022-1048 bsc#1197331 CVE-2022-49291 bsc#1238705).
- Update
patches.suse/ALSA-pcm-Fix-races-among-concurrent-prealloc-proc-wr.patch
(CVE-2022-1048 bsc#1197331 CVE-2022-49288 bsc#1238271).
- Update
patches.suse/ALSA-pcm-oss-Fix-race-at-SNDCTL_DSP_SYNC.patch
(CVE-2022-3303 bsc#1203769 CVE-2022-49733 bsc#1238454).
- Update
patches.suse/Bluetooth-hci_qca-Use-del_timer_sync-before-freeing.patch
(git-fixes CVE-2022-49555 bsc#1238231).
- Update
patches.suse/NFSD-prevent-underflow-in-nfssvc_decode_writeargs.patch
(git-fixes CVE-2022-49280 bsc#1238630).
- Update
patches.suse/PCI-Avoid-pci_dev_lock-AB-BA-deadlock-with-sriov_num.patch
(git-fixes CVE-2022-49434 bsc#1238916).
- Update
patches.suse/RDMA-hfi1-Prevent-panic-when-SDMA-is-disabled.patch
(git-fixes CVE-2022-49429 bsc#1238889).
- Update
patches.suse/SUNRPC-Fix-the-svc_deferred_event-trace-class.patch
(git-fixes CVE-2022-49065 bsc#1237739).
- Update
patches.suse/bpf-sockmap-Fix-more-uncharged-while-msg-has-more_da.patch
(bsc#1235485 CVE-2024-56633 CVE-2022-49204 bsc#1238240).
- Update
patches.suse/cgroup-Use-separate-src-dst-nodes-when-preloading-css_sets-for-migration.patch
(bsc#1201610 CVE-2022-49647 bsc#1238805).
- Update patches.suse/cifs-fix-handlecache-and-multiuser.patch
(bsc#1190317 CVE-2022-49281 bsc#1238635).
- Update
patches.suse/cifs-potential-buffer-overflow-in-handling-symlinks.patch
(bsc#1190317 CVE-2022-49058 bsc#1237814).
- Update
patches.suse/cifs-prevent-bad-output-lengths-in-smb2_ioctl_query_info-.patch
(bsc#1190317 CVE-2022-49271 bsc#1238626).
- Update patches.suse/crypto-qat-fix-memory-leak-in-RSA.patch
(git-fixes CVE-2022-49566 bsc#1238266).
- Update patches.suse/dlm-fix-plock-invalid-read.patch (git-fixes
CVE-2022-49407 bsc#1238180).
- Update
patches.suse/dm-raid-fix-KASAN-warning-in-raid5_add_disks.patch
(git-fixes CVE-2022-49673 bsc#1238933).
- Update
patches.suse/drbd-Fix-five-use-after-free-bugs-in-get_initial_state
(git-fixes CVE-2022-49085 bsc#1238036).
- Update
patches.suse/drivers-usb-host-Fix-deadlock-in-oxu_bus_suspend.patch
(git-fixes CVE-2022-49313 bsc#1238633).
- Update
patches.suse/drm-virtio-fix-NULL-pointer-dereference-in-virtio_gp.patch
(git-fixes CVE-2022-49532 bsc#1238925).
- Update
patches.suse/exec-Force-single-empty-string-when-argv-is-empty.patch
(bsc#1200571 CVE-2022-49264 bsc#1237815).
- Update patches.suse/ext4-add-reserved-GDT-blocks-check.patch
(bsc#1202712 CVE-2022-49707 bsc#1239035).
- Update patches.suse/ext4-avoid-cycles-in-directory-h-tree.patch
(bsc#1198577 CVE-2022-1184 CVE-2022-49343 bsc#1238382).
- Update patches.suse/ext4-fix-bug_on-ext4_mb_use_inode_pa.patch
(bsc#1200810 CVE-2022-49708 bsc#1238599).
- Update patches.suse/ext4-fix-bug_on-in-__es_tree_search.patch
(bsc#1200809 CVE-2022-49409 bsc#1238279).
- Update patches.suse/ext4-fix-bug_on-in-ext4_writepages.patch
(bsc#1200872 CVE-2022-49347 bsc#1238393).
- Update
patches.suse/ext4-fix-race-condition-between-ext4_write-and-ext4_.patch
(bsc#1200807 CVE-2022-49414 bsc#1238623).
- Update
patches.suse/ext4-fix-use-after-free-in-ext4_rename_dir_prepare.patch
(bsc#1200871 CVE-2022-49349 bsc#1238372).
- Update patches.suse/icmp-Fix-data-races-around-sysctl.patch
(CVE-2024-47678 bsc#1231854 git-fixes CVE-2022-49638
bsc#1238613).
- Update
patches.suse/ixgbe-Add-locking-to-prevent-panic-when-setting-srio.patch
(git-fixes CVE-2022-49584 bsc#1237933).
- Update patches.suse/list-fix-a-data-race-around-ep-rdllist.patch
(git-fixes CVE-2022-49443 bsc#1238434).
- Update
patches.suse/md-bitmap-don-t-set-sb-values-if-can-t-pass-sanity-c.patch
(bsc#1197158 CVE-2022-49526 bsc#1238030).
- Update
patches.suse/module-fix-e_shstrndx-.sh_size-0-OOB-access.patch
(git-fixes CVE-2022-49444 bsc#1238127).
- Update
patches.suse/msft-hv-2556-Drivers-hv-vmbus-Fix-potential-crash-on-module-unloa.patch
(git-fixes CVE-2022-49098 bsc#1238079).
- Update
patches.suse/mxser-fix-xmit_buf-leak-in-activate-when-LSR-0xff.patch
(git-fixes CVE-2022-49191 bsc#1238133).
- Update
patches.suse/net-asix-add-proper-error-handling-of-usb-read-error.patch
(git-fixes CVE-2022-49226 bsc#1238336).
- Update
patches.suse/nvme-pci-fix-a-NULL-pointer-dereference-in-nvme_allo.patch
(git-fixes CVE-2022-49492 bsc#1238954).
- Update
patches.suse/ocfs2-dlmfs-fix-error-handling-of-user_dlm_destroy_l.patch
(git-fixes CVE-2022-49337 bsc#1238376).
- Update
patches.suse/powerpc-pseries-Fix-use-after-free-in-remove_phb_dyn.patch
(bsc#1065729 bsc#1198660 ltc#197803 CVE-2022-49196 bsc#1238274).
- Update
patches.suse/powerpc-tm-Fix-more-userspace-r13-corruption.patch
(bsc#1065729 CVE-2022-49164 bsc#1238108).
- Update
patches.suse/powerpc-xics-fix-refcount-leak-in-icp_opal_init.patch
(bsc#1065729 CVE-2022-49432 bsc#1238950).
- Update
patches.suse/powerpc-xive-Fix-refcount-leak-in-xive_spapr_init.patch
(fate#322438 git-fixes CVE-2022-49437 bsc#1238443).
- Update
patches.suse/powerpc-xive-spapr-correct-bitmap-allocation-size.patch
(fate#322438 git-fixes CVE-2022-49623 bsc#1239040).
- Update
patches.suse/scsi-libfc-Fix-use-after-free-in-fc_exch_abts_resp.patch
(git-fixes CVE-2022-49114 bsc#1238146).
- Update
patches.suse/scsi-lpfc-Address-NULL-pointer-dereference-after-sta.patch
(git-fixes CVE-2022-49332 bsc#1238236).
- Update
patches.suse/scsi-pm8001-Fix-abort-all-task-initialization
(git-fixes CVE-2022-49217 bsc#1238313).
- Update
patches.suse/scsi-qla2xxx-Fix-crash-during-module-load-unload-tes.patch
(bsc#1197661 CVE-2022-49160 bsc#1238172).
- Update
patches.suse/scsi-qla2xxx-Fix-premature-hw-access-after-PCI-error.patch
(bsc#1195823 CVE-2022-49157 bsc#1238169).
- Update
patches.suse/scsi-qla2xxx-Fix-scheduling-while-atomic.patch
(bsc#1195823 CVE-2022-49156 bsc#1238168).
- Update
patches.suse/scsi-qla2xxx-Fix-warning-message-due-to-adisc-being-.patch
(bsc#1195823 CVE-2022-49158 bsc#1238170).
- Update
patches.suse/scsi-qla2xxx-Implement-ref-count-for-SRB.patch
(bsc#1195823 CVE-2022-49159 bsc#1238171).
- Update
patches.suse/scsi-qla2xxx-Suppress-a-kernel-complaint-in-qla_crea.patch
(bsc#1195823 CVE-2022-49155 bsc#1237941).
- Update
patches.suse/scsi-zorro7xx-Fix-a-resource-leak-in-zorro7xx_remove_one
(git-fixes CVE-2022-49095 bsc#1237752).
- Update
patches.suse/tcp-fix-tcp_mtup_probe_success-vs-wrong-snd_cwnd.patch
(bsc#1218450 CVE-2022-49330 bsc#1238378).
- Update
patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
(CVE-2022-2977 bsc#1202672 CVE-2022-49287 bsc#1238276).
- Update
patches.suse/tracing-Fix-sleeping-function-called-from-invalid-context-on-RT-kernel.patch
(git-fixes CVE-2022-49322 bsc#1238396).
- Update
patches.suse/usb-dwc2-Fix-memory-leak-in-dwc2_hcd_init.patch
(git-fixes CVE-2022-49713 bsc#1238419).
- Update
patches.suse/usb-usbip-fix-a-refcount-leak-in-stub_probe.patch
(git-fixes CVE-2022-49389 bsc#1238257).
- Update patches.suse/usbnet-fix-memory-leak-in-error-case.patch
(git-fixes CVE-2022-49657 bsc#1238269).
- Update
patches.suse/veth-Ensure-eth-header-is-in-skb-s-linear-part.patch
(git-fixes CVE-2022-49066 bsc#1237722).
- Update
patches.suse/video-fbdev-clcdfb-Fix-refcount-leak-in-clcdfb_of_vr.patch
(bsc#1129770 CVE-2022-49421 bsc#1238819).
- Update
patches.suse/virtio_console-eliminate-anonymous-module_init-modul.patch
(git-fixes CVE-2022-49100 bsc#1237735).
- Update
patches.suse/virtio_net-fix-xdp_rxq_info-bug-after-suspend-resume.patch
(git-fixes CVE-2022-49687 bsc#1238181).
- Update
patches.suse/x86-speculation-fill-rsb-on-vmexit-for-ibrs.patch
(bsc#1201726 CVE-2022-26373 CVE-2022-49611 bsc#1238618).
- Update
patches.suse/xen-netback-avoid-entering-xenvif_rx_next_skb-with-a.patch
(bsc#1201381 CVE-2022-49649 bsc#1238612).
- Update
patches.suse/xprtrdma-treat-all-calls-not-a-bcall-when-bc_serv-is.patch
(git-fixes CVE-2022-49321 bsc#1238373).
- commit c156b3c
- Update
patches.suse/0008-video-fbdev-smscufx-Fix-null-ptr-deref-in-ufx_usb_pr.patch
(bsc#1129770 CVE-2021-47652 bsc#1237721).
- Update
patches.suse/ath5k-fix-OOB-in-ath5k_eeprom_read_pcal_info_5111.patch
(git-fixes CVE-2021-47633 bsc#1237768).
- commit 9ae3067
- rdma/cxgb4: Prevent potential integer overflow on 32bit (CVE-2024-57973 bsc#1238531)
- commit dbbc8b2
- RDMA/hfi1: Fix potential integer multiplication overflow errors (CVE-2022-49404 bsc#1238430)
- commit 80a20e6
- nfc: nci: add flush_workqueue to prevent uaf (CVE-2022-49059 bsc#1238007)
- commit 305c681
- ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg (CVE-2022-49727 bsc#1239059)
- commit 7f3b150
- can: m_can: m_can_tx_handler(): fix use after free of skb (CVE-2022-49275 bsc#1238719)
- commit 1fdfcc6
- crypto: qat - add param check for DH (CVE-2022-49564 bsc#1238789)
- commit 7f4f28c
- crypto: qat - add param check for RSA (CVE-2022-49563 bsc#1238787)
- commit f87e665
- wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014 bsc#1239109)
- commit fe78d7b
- orangefs: fix a oob in orangefs_debug_write (git-fixes
bsc#1239117 CVE-2025-21782).
- commit 6a7a2b9
- ALSA: jack: Fix mutex call in snd_jack_report() (CVE-2022-49538
bsc#1238843).
- commit 0a9be43
- kABI workaround for snd_jack.input_dev_lock field
(CVE-2022-49538 bsc#1238843).
- commit 0decf9d
- ALSA: jack: Access input_dev under mutex (CVE-2022-49538
bsc#1238843).
- ath10k: skip ath10k_halt during suspend for driver state
RESTARTING (CVE-2022-49519 bsc#1238943).
- commit b758634
- extcon: Modify extcon device to be created after driver data
is set (CVE-2022-49308 bsc#1238654).
- commit bb2d5d7
- ALSA: oss: Fix PCM OSS buffer allocation overflow
(CVE-2022-49292 bsc#1238625).
- commit 05f3e03
- wifi: rtlwifi: remove unused check_buddy_priv (CVE-2024-58072
bsc#1238964).
- commit ca6cdaf
- perf/core: Fix data race between perf_event_set_output()
and perf_mmap_close() (CVE-2022-49607 bsc#1238817).
- commit 7d0651a
- packaging: Patch Makefile to pre-select gcc version (jsc#PED-12251).
When compiler different from the one which was used to configure the
kernel is used to build modules a warning is issued and the build
continues. This could be turned into an error but that would be too
restrictive.
The generated kernel-devel makefile could set the compiler but then the
main Makefile as to be patched to assign CC with ?=
This causes run_oldconfig failure on SUSE-2024 and kbuild config check
failure on SUSE-2025.
This cannot be hardcoded to one version in a regular patch because the
value is expected to be configurable at mkspec time. Patch the Makefile
after aplyin patches in rpm prep step instead. A check is added to
verify that the sed command did indeed apply the change.
- commit 6031391
- kABI workaround for pps changes (CVE-2024-57979 bsc#1238521).
- commit ecc73ae
- pps: Fix a use-after-free (CVE-2024-57979 bsc#1238521).
- commit 5e01f6b
- net: hns3: fix oops when unload drivers paralleling
(CVE-2025-21802 bsc#1238751).
- be2net: Fix buffer overflow in be_get_module_eeprom
(CVE-2022-49581 bsc#1238540).
- commit f8f5e83
- rpm/split-modules: Fix optional splitting with usrmerge (bsc#1238570)
- commit 8be63c4
- tpm: use try_get_ops() in tpm-space.c (CVE-2022-49286
bsc#1238647).
- commit 0f153ea
- ipvs: fix UB due to uninitialized stack access in
ip_vs_protocol_init() (CVE-2024-53680 bsc#1235715).
- commit 8dac11a
- kABI workaround for bluetooth hci_conn struct change
(CVE-2024-36968 bsc#1226130).
- commit be09290
- Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
(CVE-2024-36968 bsc#1226130).
- commit 930b6c7
- scsi: qedf: Ensure the copied buf is NUL terminated
(CVE-2024-38559 bsc#1226785).
- commit 15b9d87
- packaging: Turn gcc version into config.sh variable
Fixes: 51dacec21eb1 ("Use gcc-13 for build on SLE16 (jsc#PED-10028).")
- commit 011d54b
- 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
- kABI fix for net/smc: fix kernel panic caused by race of
smc_sock (CVE-2021-46925 bsc#1220466).
Upstream commit 349d43127dac ("net/smc: fix kernel panic caused
by race of smc_sock") introduced two new variables into `struct
smc_connection`, which is not public, but still privately exposed.
Since allocation always happens via `smcd_alloc_dev()` we should be
safe to simply hide the symbols for the kABI checker.
- commit 5f5274c
- drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is (bsc#1238275 CVE-2022-49490)
- commit af254cd
- net/smc: fix kernel panic caused by race of smc_sock
(CVE-2021-46925 bsc#1220466).
- commit a03d2f6
- rpm/kernel-docs.spec.in: Workaround for reproducible builds (bsc#1238303)
- commit 1f1e842
- 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
- net/smc: Remove unused function declaration (CVE-2021-46925
bsc#1220466).
- commit c673437
- 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 "[uprobes]" 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
- gro_cells: Avoid packet re-ordering for cloned skbs
(bsc#1226323).
- commit 31d3c95
- nfsd: restore callback functionality for NFSv4.0 (CVE-2024-53217 bsc#1234999)
- commit 805ad92
- add nf_tables for iptables non-legacy network handling
This is needed for example by docker on the Alpine Linux distribution,
but can also be used on openSUSE.
- commit f9b0903
- 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
- kernel-source: Also replace bin/env
- commit dc2037c
- 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
- Fix conditional for selecting gcc-13
Fixes: 51dacec21eb1 ("Use gcc-13 for build on SLE16 (jsc#PED-10028).")
- commit 07542ae
- 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->nsproxy (CVE-2025-21640 bsc#1236123)
- commit fcc1d3a
- sctp: sysctl: rto_min/max: avoid using current->nsproxy (CVE-2025-21639 bsc#1236122)
- commit cef2fdd
- sctp: sysctl: auth_enable: avoid using current->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
- Use gcc-13 for build on SLE16 (jsc#PED-10028).
- commit 51dacec
- 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 ("eth: bnxt:
always recalculate features after XDP clearing, fix null-deref
(CVE-2025-21682 bsc#1236703).")
- 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 ("net: defer final 'struct
net' free in netns dismantle") 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->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
- doc/README.SUSE: Point to the updated version of LKMPG
- commit 624b259
- 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->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 "fbdev: efifb: Register sysfs groups through driver core"
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 "driver core: add dev_groups to all drivers (bsc#1232224"
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 "driver core: kABI workaround for dev_groups in device_driver"
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 "driver core: Fix error return code in really_probe()"
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->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->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
- rpm/kernel-binary.spec.in: fix KMPs build on 6.13+ (bsc#1234454)
Upstream commit 822b11a74ba2 (kbuild: use absolute path in the generated
wrapper Makefile) sets also KBUILD_OUTPUT in objdir's Makefile before
including srcdir's Makefile.
So emulate this too, otherwise KMPs fail to build:
/usr/src/linux-6.13.0-rc2-1.gf92fc5d/Makefile:782: /usr/src/linux-6.13.0-rc2-1.gf92fc5d/include/config/auto.conf: No such file or directory
- commit 46168e5
- 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
- x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client (bsc#1234072 CVE-2024-53114).
- commit ace41bd
- kABI: Restore deleted EXPORT_SYMBOL(__qdisc_calculate_pkt_len)
(CVE-2024-50039 bsc#1231909).
- commit 127915c
- Update
patches.suse/initramfs-avoid-filename-buffer-overrun.patch
(CVE-2024-53142 bsc#1232436).
- commit c12c103
- net/sched: accept TCA_STAB only for root qdisc (CVE-2024-50039
bsc#1231909).
- commit e5bb59d
- Bluetooth: af_bluetooth: Fix deadlock (CVE-2024-26886
bsc#1223044).
- Bluetooth: Avoid potential use-after-free in hci_error_reset
(CVE-2024-26801 bsc#1222413).
- commit 0002c48
- dm cache: fix potential out-of-bounds access on the first resume
(bsc#1233467, CVE-2024-50278).
- dm cache: optimize dirty bit checking with find_next_bit when
resizing (bsc#1233467, CVE-2024-50278).
- commit 0b89286
- Update References: field,
patches.suse/dm-cache-fix-out-of-bounds-access-to-the-dirty-bitset-when-resizing.patch
(bsc#1233467, bsc#1233468, CVE-2024-50278, CVE-2024-50279).
- commit 3ad9690
- dm cache: fix flushing uninitialized delayed_work on cache_ctr
error (bsc#1233467, CVE-2024-50278).
- dm cache: correct the number of origin blocks to match the
target length (bsc#1233467, CVE-2024-50278).
- commit 4bc71b8
- can: bcm: Clear bo->bcm_proc_read after remove_proc_entry()
(CVE-2024-46771 bsc#1230766).
- commit 491eb77
- ocfs2: uncache inode which has failed entering the group (bsc#1234087).
- commit 8d46222
- sch/netem: fix use after free in netem_dequeue (CVE-2024-46800
bsc#1230827).
- can: bcm: Remove proc entry when dev is unregistered
(CVE-2024-46771 bsc#1230766).
- commit 4db26bc
- media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED
in uvc_parse_format (CVE-2024-53104 bsc#1234025).
- commit 5e374e6
- icmp: change the order of rate limits (CVE-2024-47678 bsc#1231854).
- icmp: Fix data-races around sysctl (CVE-2024-47678 bsc#1231854).
- commit d0baf4a
- USB: serial: io_edgeport: fix use after free in debug printk (CVE-2024-50267 bsc#1233456)
- commit 5cba6cd
- usb: typec: altmode should keep reference to parent (CVE-2024-50150 bsc#1233051)
- commit 42ad9b3
- net: hns3: fix kernel crash when uninstalling driver (CVE-2024-50296 bsc#1233485)
- commit 184c4c0
- netrom: fix possible dead-lock in nr_rt_ioctl() (CVE-2024-38589
bsc#1226748).
- commit 7feed5d
- tipc: fix UAF in error path (CVE-2024-36886 bsc#1225730).
- commit cad363a
- net: fix out-of-bounds access in ops_init (CVE-2024-36883
bsc#1225725).
- commit 30e3698
- drm/vc4: Warn if some v3d code is run on BCM2711 (bsc#1233108)
Only take struct vc4file.dev for bsc#1233108. Leave out the commit's
tests and warnings.
- commit 7eeddbe
- mm: memory.stat allow preemption (bsc#1231877).
- commit 5ec6726
- memcg: reduce memcg tree traversals for stats collection
(bsc#1231877).
- commit a81a392
- net: relax socket state check at accept time (git-fixes).
- commit 4a31544
- tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
(CVE-2024-36905 bsc#1225742).
- commit 9ad4cc7
- drm/vc4: Stop the active perfmon before being destroyed (bsc#1233108 CVE-2024-50187)
- commit f0f44d8
- wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit (CVE-2024-49938 bsc#1232552)
- commit 4092e67
- sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start (CVE-2024-49944 bsc#1232166)
- commit dc87660
- netfilter: nf_tables: prevent nf_skb_duplicated corruption (CVE-2024-49952 bsc#1232157)
- commit 0b60580
- security/keys: fix slab-out-of-bounds in key_task_permission
(CVE-2024-50301 bsc#1233490).
- commit 6e6d2aa
- media: cx24116: prevent overflows on SNR calculus
(CVE-2024-50290 bsc#1233479).
- commit 12a43db
- dm cache: fix out-of-bounds access to the dirty bitset when
resizing (CVE-2024-50279 bsc#1233468).
- commit a5eeed1
- nvme-pci: fix race condition between reset and
nvme_dev_disable() (bsc#1232888 CVE-2024-50135).
- commit d800691
- scsi: lpfc: Ensure DA_ID handling completion before deleting
an NPIV instance (bsc#1233130 CVE-2024-50183).
- commit 2341eee
- tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink()
(CVE-2024-50154 bsc#1233070).
Patch has been manually modified to apply.
- commit e2aba08
- nfs: Fix KMSAN warning in decode_getfattr_attrs()
(CVE-2024-53066 bsc#1233560).
- commit b4e2ec3
- btrfs: fix a NULL pointer dereference when failed to start a
new trasacntion (CVE-2024-49868 bsc#1232272).
- commit 28e08c8
- Reinstate some of "swiotlb: rework "fix info leak with
DMA_FROM_DEVICE"" (CVE-2022-48853 bsc#1228015).
- commit ddba53c
- HID: core: zero-initialize the report buffer (CVE-2024-50302
bsc#1233491).
- commit 6bc7fd8
- vsock/virtio: Initialization of the dangling pointer occurring
in vsk->trans (CVE-2024-50264 bsc#1233453).
- commit edf6fa0
- net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged
SKB data (CVE-2024-53058 bsc#1233552).
- commit ebde361
- Bluetooth: SCO: Fix UAF on sco_sock_timeout (CVE-2024-50125
bsc#1232928).
- Bluetooth: call sock_hold earlier in sco_conn_del
(CVE-2024-50125 bsc#1232928).
- commit 4838e6d
- Update
patches.suse/posix-clock-posix-clock-Fix-unbalanced-locking-in-pc.patch
(CVE-2024-50195 bsc#1233103 CVE-2024-50210 bsc#1233097).
- commit 4b1cf97
- mm: revert "mm: shmem: fix data-race in shmem_getattr()"
(CVE-2024-50228, bsc#1233204, git fixes (mm/shmem)).
- commit 84efe19
- posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit dede472
- media: av7110: fix a spectre vulnerability (CVE-2024-50289
bsc#1233478).
- commit 43a6f6e
- efi/memattr: Ignore table if the size is clearly bogus
(CVE-2024-49858 bsc#1232251 bsc#1231465).
- commit 3272541
- i40e: fix race condition by adding filter's intermediate sync
state (CVE-2024-53088 bsc#1233580).
- i40e: fix i40e_count_filters() to count only active/new filters
(CVE-2024-53088 bsc#1233580).
- commit c0c4369
- ocfs2: remove entry once instead of null-ptr-dereference in
ocfs2_xa_remove() (bsc#1233454 CVE-2024-50265).
- commit 3e0d522
- net: hns3: fix a deadlock problem when config TC during
resetting (CVE-2024-44995 bsc#1230231).
- commit 398b1db
- media: dvbdev: prevent the risk of out of memory access
(CVE-2024-53063 bsc#1233557).
- commit 62f1f9b
- tpm: Lock TPM chip in tpm_pm_suspend() first (bsc#1082555
git-fixes CVE-2024-53085 bsc#1233577).
- commit 70d272c
- media: s5p-jpeg: prevent buffer overflows (CVE-2024-53061
bsc#1233555).
- commit 506c426
- Update
patches.suse/tipc-fix-a-possible-memleak-in-tipc_buf_append.patch
(bsc#1221977 CVE-2021-47162 bsc#1225764 CVE-2024-36954
CVE-2024-36886 bsc#1225730).
- commit 6b7c8a5
- net: netem: use a list in addition to rbtree
(git-fixes CVE-2024-45016 bsc#1230429).
- commit 2b0774f
- swiotlb: fix info leak with DMA_FROM_DEVICE (CVE-2022-48853
bsc#1228015).
- commit 56fe90d
- crypto: ecdh - explicitly zeroize private_key (CVE-2024-42098
bsc#1228779).
- commit ef82dbf
- crypto: aead,cipher - zeroize key buffer after use
(CVE-2024-42229 bsc#1228708).
- commit 1b83698
- btrfs: reinitialize delayed ref list after deleting it from
the list (bsc#1233462 CVE-2024-50273).
- commit 0901f0b
- Refresh
patches.suse/net-prevent-mss-overflow-in-skb_segment.patch.
Fix the following warning:
net/core/skbuff.c: In function 'skb_segment':
include/linux/kernel.h:795:16: warning: comparison of distinct pointer types lacks a cast [enabled by default]
include/linux/kernel.h:798:2: note: in expansion of macro '__min'
net/core/skbuff.c:3302:18: note: in expansion of macro 'min'
This is how the warning got silenced in upstream stable kernel
v4.19.321.
- commit 68ad1ea
- Refresh
patches.suse/scsi-lpfc-Validate-hdwq-pointers-before-dereferencin.patch.
Adjust the backport to match the old size of struct members. This
fixes the following warning:
../drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli_flush_io_rings':
../drivers/scsi/lpfc/lpfc_sli.c:4436:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'int' [-Wformat=]
../drivers/scsi/lpfc/lpfc_sli.c:4436:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'uint32_t' [-Wformat=]
- commit dff4c6e
- kernel-binary: Enable livepatch package only when livepatch is enabled
Otherwise the filelist may be empty failing the build (bsc#1218644).
- commit f730eec
- Update config files (bsc#1218644).
LIVEPATCH_IPA_CLONES=n => LIVEPATCH=n
- commit b1b7b65
- posix-clock: Fix missing timespec64 check in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit 41e678c
- net: systemport: fix potential memory leak in bcm_sysport_xmit() (CVE-2024-50171 bsc#1233057)
- commit a8cf9c8
- Bluetooth: bnep: fix wild-memory-access in proto_unregister (CVE-2024-50148 bsc#1233063)
- commit cb3dc55
- tty: n_gsm: Fix use-after-free in gsm_cleanup_mux (CVE-2024-50073 bsc#1232520)
- commit 68babec
- Update
patches.suse/arm64-probes-Fix-uprobes-for-big-endian-kernels.patch
(git-fixes CVE-2024-50194 bsc#1233111).
- Update
patches.suse/arm64-probes-Remove-broken-LDR-literal-uprobe-support.patch
(git-fixes CVE-2024-50099 bsc#1232887).
- Update
patches.suse/ceph-remove-the-incorrect-Fw-reference-check-when-dir.patch
(bsc#1231184 CVE-2024-50179 bsc#1233123).
- commit c9a203b
- ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
(bsc#1233191 CVE-2024-50218).
- commit cc4dbc4
- Update tags in
patches.suse/ext4-fix-slab-use-after-free-in-ext4_split_extent_at.patch
(bsc#1232201 CVE-2024-49884 bsc#1232198).
- commit dcc8f26
- Fix compiler warnings introduced in
patches.suse/udf-Avoid-excessive-partition-lengths.patch.
- commit fc54634
- mm: shmem: fix data-race in shmem_getattr() (CVE-2024-50228,
bsc#1233204, git fixes (mm/shmem)).
- commit e71d93b
- driver core: bus: Fix double free in driver API bus_register()
(bsc#1232329 CVE-2024-50055).
- commit 0448963
- KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
(CVE-2024-50115 bsc#1232919).
- commit 0050d80
- drm/amd: Guard against bad data for ATIF ACPI method (bsc#1232897 CVE-2024-50117)
- commit 97c9929
- wifi: mac80211: do not pass a stopped vif to the driver in
.get_txpower (CVE-2024-50237 bsc#1233216).
- commit 6d8f0b7
- wifi: ath10k: Fix memory leak in management tx (CVE-2024-50236
bsc#1233212).
- commit 0b6cbda
- wifi: iwlegacy: Clear stale interrupts before resuming device
(CVE-2024-50234 bsc#1233211).
- commit 01cb9ce
- drm/amd/display: Check null pointers before used (bsc#1232371 CVE-2024-49921)
- commit e8deeae
- net/ncsi: Disable the ncsi work before freeing the associated
structure (CVE-2024-49945 bsc#1232165).
- commit a88491e
- Update tags
patches.suse/mm-Avoid-overflows-in-dirty-throttling-logic.patch
(bsc#1222364 CVE-2024-42131 bsc#1228650).
- commit 3f14d21
- RDMA/mad: Improve handling of timed out WRs of mad agent (bsc#1232873 CVE-2024-50095)
- commit 2d90f41
- IB/mad: Issue complete whenever decrements agent refcount (bsc#1232873 CVE-2024-50095)
- commit 27da1c4
- be2net: fix potential memory leak in be_xmit() (CVE-2024-50167
bsc#1233049).
- commit 4f25cff
- cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations
(CVE-2024-27051 bsc#1223769).
- commit 6437a99
- driver core: Fix error return code in really_probe()
(bsc#1232224 CVE-2024-49925).
- commit 7264309
- parport: Proper fix for array out-of-bounds access (CVE-2024-50074 bsc#1232507)
- commit ee8e094
- cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's
return value (CVE-2024-27051 bsc#1223769).
- commit e56562b
- vfs: fix race between evice_inodes() and find_inode()&iput()
(bsc#1231930 CVE-2024-47679).
- commit ebf12b1
- ext4: avoid OOB when system.data xattr changes underneath the
filesystem (bsc#1231920 CVE-2024-47701).
- commit 06b6d21
- ext4: explicitly exit when ext4_find_inline_entry returns an
error (bsc#1231920 CVE-2024-47701).
- commit 76db0bc
- ext4: return error on ext4_find_inline_entry (bsc#1231920
CVE-2024-47701).
- commit 3ce9700
- ext4: ext4_search_dir should return a proper error (bsc#1231920
CVE-2024-47701).
- commit 35d9543
- wifi: cfg80211: check A-MSDU format more carefully (stable-fixes
CVE-2024-35937 bsc#1224526).
- blacklist.conf: remove the entry that we're just adding
- commit efe6631
- driver core: kABI workaround for dev_groups in device_driver
(bsc#1232224 CVE-2024-49925).
- commit 993ec78
- initramfs: avoid filename buffer overrun (bsc#1232436).
- commit 7ae8606
- driver core: add dev_groups to all drivers (bsc#1232224
CVE-2024-49925).
- commit d16dce7
- fbdev: efifb: Register sysfs groups through driver core
(bsc#1232224 CVE-2024-49925).
- commit bff3087
- NFC: nci: Bounds check struct nfc_target arrays (bsc#1232304 CVE-2022-48967)
- commit 5a26fef
- net: hisilicon: Fix potential use-after-free in hix5hd2_rx() (bsc#1231979 CVE-2022-48960)
- commit e5b93cf
- kabi/severities: ignore amdgpu symbols
amdkfd symbols are exported but they are supposed to be used only
by amdgpu, so they are local symbols that can be ignored.
- commit 381c434
- ipv6: avoid use-after-free in ip6_fragment() (CVE-2022-48956
bsc#1231893).
- commit fea62f0
- scsi: lpfc: Validate hdwq pointers before dereferencing in
reset/errata paths (bsc#1232218 CVE-2024-49891).
- commit b5db475
- SLE12-SP5 turned LTSS (Extended Security) - maintainership goes to L3
- commit 6e14d1d
- Bluetooth: RFCOMM: FIX possible deadlock in
rfcomm_sk_state_change (CVE-2024-50044 bsc#1231904).
- commit e681821
- tipc: guard against string buffer overrun (CVE-2024-49995
bsc#1232432).
- commit ba288b6
- net/xen-netback: prevent UAF in xenvif_flush_hash()
(CVE-2024-49936 bsc#1232424).
- commit 2fa13cf
- drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer
(CVE-2024-49991 bsc#1232282).
- commit ce009ae
- Remove duplicate CVE references
Update patches.suse/nvme-fix-a-possible-use-after-free-in-controller-res.patch
Update patches.suse/nvme-rdma-fix-possible-use-after-free-in-transport-e.patch
Update patches.suse/nvme-tcp-fix-possible-use-after-free-in-transport-er.patch
- commit 2663e32
- mm: split critical region in remap_file_pages() and invoke
LSMs in between (CVE-2024-47745 bsc#1232135 git-fix).
- commit 661d796
- nfs: fix memory leak in error path of nfs4_do_reclaim
(git-fixes).
- nfsd: fix delegation_blocked() to block correctly for at least
30 seconds (git-fixes).
- commit 05c4d99
- Update
patches.suse/IB-core-Implement-a-limit-on-UMAD-receive-List.patch
(bsc#1228743 CVE-2024-42145 bsc#1223384).
- Update
patches.suse/RDMA-cxgb4-Added-NULL-check-for-lookup_atid.patch
(git-fixes CVE-2024-47749 bsc#1232180).
- Update
patches.suse/RDMA-iwcm-Fix-WARNING-at_kernel-workqueue.c-check_fl.patch
(git-fixes CVE-2024-47696 bsc#1231864).
- Update
patches.suse/aoe-fix-the-potential-use-after-free-problem-in-more.patch
(bsc#1218562 CVE-2023-6270 CVE-2024-49982 bsc#1232097).
- Update patches.suse/media-edia-dvbdev-fix-a-use-after-free.patch
(CVE-2024-27043 bsc#1223824 bsc#1218562).
- Update
patches.suse/ocfs2-fix-null-ptr-deref-when-journal-load-failed.patch
(git-fixes CVE-2024-49957 bsc#1232152).
- Update
patches.suse/ocfs2-fix-possible-null-ptr-deref-in-ocfs2_set_buffer_uptodate.patch
(git-fixes CVE-2024-49877 bsc#1232339).
- Update
patches.suse/ocfs2-remove-unreasonable-unlock-in-ocfs2_read_blocks.patch
(git-fixes CVE-2024-49965 bsc#1232142).
- commit d1259c0
- Update
patches.suse/nfc-nci-fix-possible-NULL-pointer-dereference-in-sen.patch
(bsc#1219125 CVE-2023-46343 CVE-2023-52919 bsc#1231988).
- Update
patches.suse/tcp-do-not-accept-ACK-of-bytes-we-never-sent.patch
(CVE-2023-52881 bsc#1225611 bsc#1223384).
- commit 9477732
- Update
patches.suse/char-tpm-Protect-tpm_pm_suspend-with-locks.patch
(bsc#1082555 CVE-2022-48997 bsc#1232035).
- Update
patches.suse/igb-Initialize-mailbox-message-for-VF-reset.patch
(git-fixes CVE-2022-48949 bsc#1231897).
- Update
patches.suse/net-mana-Fix-race-on-per-CQ-variable-napi-work_done.patch
(bsc#1229154 CVE-2022-48985 bsc#1231958).
- Update
patches.suse/nvme-fix-a-possible-use-after-free-in-controller-res.patch
(bsc#1227941 (CVE-2022-48790) CVE-2022-48790).
- Update
patches.suse/nvme-rdma-fix-possible-use-after-free-in-transport-e.patch
(bsc#1227952 (CVE-2022-48788) CVE-2022-48788).
- Update
patches.suse/nvme-tcp-fix-possible-use-after-free-in-transport-er.patch
(bsc#1228000 (CVE-2022-48789) CVE-2022-48789).
- Update
patches.suse/udf-Fix-preallocation-discarding-at-indirect-extent-.patch
(bsc#1213034 CVE-2022-48946 bsc#1231888).
- Update
patches.suse/xen-netfront-Fix-NULL-sring-after-live-migration.patch
(git-fixes CVE-2022-48969 bsc#1232026).
- commit c8e7e6a
- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
bsc#1225336 CVE-2021-47416 bsc#1225189).
- commit 9036983
- smb: client: fix UAF in async decryption (bsc#1232418,
CVE-2024-50047).
- commit f679375
- drm/amd/display: Fix index out of bounds in degamma hardware format translation (CVE-2024-49894 bsc#1232354)
- commit b558147
- drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs (CVE-2024-49901 bsc#1232305)
- commit 9c2561f
- ext4: fix i_data_sem unlock order in ext4_ind_migrate() (CVE-2024-50006 bsc#1232442)
- commit 8639f10
- ALSA: asihpi: Fix potential OOB array access (CVE-2024-50007 bsc#1232394)
- commit 013518a
- jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error (CVE-2024-49959 bsc#1232149)
- commit 284567a
- ACPI: sysfs: validate return type of _STR method (bsc#1231861
CVE-2024-49860).
- commit aede924
- mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
(CVE-2022-48991 bsc#1232070).
- commit bc2150c
- mm/khugepaged: fix GUP-fast interaction by sending IPI
(CVE-2022-48991 bsc#1232070 prerequisity).
- commit 1df90ba
- khugepaged: retract_page_tables() remember to test exit
(CVE-2022-48991 bsc#1232070 prerequisity).
- commit f4a1619
- ext4: update orig_path in ext4_find_extent() (CVE-2024-49881 bsc#1232201)
- commit b5dc210
- ext4: fix slab-use-after-free in ext4_split_extent_at() (bsc#1232201)
- commit 693aa17
- btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info()
in walk_down_proc() (CVE-2024-46841 bsc#1231094).
- commit 6d306f6
- ext4: aovid use-after-free in ext4_ext_insert_extent() (CVE-2024-49883 bsc#1232199)
- commit ec16b20
- wifi: iwlwifi: mvm: avoid NULL pointer dereference (CVE-2024-49929 bsc#1232253)
- commit 84425bf
- net: fix a memleak when uncloning an skb dst and its metadata
(CVE-2022-48809 bsc#1227947).
- commit 2bf5e2a
- tpm: Clean up TPM space after command failure (CVE-2024-49851
bsc#1232134).
- commit 7bbb5a1
- serial: protect uart_port_dtr_rts() in uart_shutdown() too
(CVE-2024-50058 bsc#1232285).
- commit 41b7884
- ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() (CVE-2024-49962 bsc#1232314)
- commit 4df8d00
- drm/amd/display: Check stream before comparing them (CVE-2024-49896 bsc#1232221)
- commit b1fe975
- drm/amd/pm: ensure the fw_info is not null before using it (CVE-2024-49890 bsc#1232217)
- commit c3be196
- ASoC: ops: Correct bounds check for second channel on SX controls (CVE-2022-48951 bsc#1231929)
- commit bf654bc
- firmware_loader: Block path traversal (CVE-2024-47742 bsc#1232126)
- commit 7af5448
- ASoC: soc-pcm: Add NULL check in BE reparenting (CVE-2022-48992 bsc#1232071)
- commit 70e6117
- media: pci: cx23885: check cx23885_vdev_init() return (CVE-2023-52918 bsc#1232047)
- commit 713adf4
- ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() (CVE-2022-48951 bsc#1231929)
- commit 26bb290
- btrfs: clean up our handling of refs == 0 in snapshot delete (CVE-2024-46840 bsc#1231105)
- commit 61febb6
- drm/amd/display: Check null pointers before multiple uses (bsc#1232313 CVE-2024-49920)
- commit 2448039
- iommu/vt-d: Fix PCI device refcount leak in has_external_pci()
(bsc#1232123 CVE-2022-49000).
- commit 02b654b
- net: mvneta: Fix an out of bounds check (CVE-2022-48966
bsc#1232191).
- commit 0317c39
- iommu/vt-d: Fix PCI device refcount leak in
dmar_dev_scope_init() (bsc#1232133 CVE-2022-49002).
- commit 5c0b5c2
- net: hisilicon: Fix potential use-after-free in hisi_femac_rx()
(CVE-2022-48962 bsc#1232286).
- commit fc49b9f
- ppp: fix ppp_async_encode() illegal access (CVE-2024-50035
bsc#1232392).
- net: avoid potential underflow in qdisc_pkt_len_init() with UFO
(CVE-2024-49949 bsc#1232160).
- net: mvneta: Prevent out of bounds read in mvneta_config_rss()
(CVE-2022-48966 bsc#1232191).
- net/9p: Fix a potential socket leak in p9_socket_open
(CVE-2022-49020 bsc#1232175).
- commit 2c23eba
- hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()
(bsc#1232006 CVE-2022-49011).
- hwmon: (coretemp) Check for null before removing sysfs attrs
(bsc#1232172 CVE-2022-49010).
- hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc()
fails (bsc#1231995 CVE-2022-49029).
- commit 71880ba
- Update
patches.suse/0001-x86-kaslr-Expose-and-use-the-end-of-the-physical-mem.patch
(bsc#1230405, bsc#1232236).
- commit a8a279f
- mm: call the security_mmap_file() LSM hook in remap_file_pages()
(CVE-2024-47745 bsc#1232135).
- commit ed0f269
- Bluetooth: L2CAP: Fix uaf in l2cap_connect (CVE-2024-49950
bsc#1232159).
- commit 30ab1b9
- arm64: probes: Fix uprobes for big-endian kernels (git-fixes)
- commit 3e6f9a6
- arm64: probes: Fix simulate_ldr*_literal() (git-fixes)
- commit a1137d7
- arm64: probes: Remove broken LDR (literal) uprobe support (git-fixes)
- commit e35a346
- arm64: esr: Define ESR_ELx_EC_* constants as UL (git-fixes)
- commit 03723c2
- ext4: fix double brelse() the buffer of the extents path
(bsc#1232200 CVE-2024-49882).
- ext4: no need to continue when the number of entries is 1
(bsc#1232140 CVE-2024-49967).
- commit fc369f8
- ethernet: aeroflex: fix potential skb leak in greth_init_rings()
(CVE-2022-48958 bsc#1231889).
- e100: Fix possible use after free in e100_xmit_prepare
(CVE-2022-49026 bsc#1231997).
- iavf: Fix error handling in iavf_init_module() (CVE-2022-49027
bsc#1232007).
- ixgbevf: Fix resource leak in ixgbevf_init_module()
(CVE-2022-49028 bsc#1231996).
- net: phy: fix null-ptr-deref while probe() failed
(CVE-2022-49021 bsc#1231939).
- commit ed7ba02
- net: usb: usbnet: fix name regression (get-fixes).
- commit 505fee4
- drm/amd/display: Check gpio_id before used as array index (CVE-2024-46818 bsc#1231203).
- commit 38ee0dd
- drbd: Fix atomicity violation in drbd_uuid_set_bm() (git-fixes).
- drbd: Add NULL check for net_conf to prevent dereference in
state validation (git-fixes).
- commit 8ea7f3b
- gpio: amd8111: Fix PCI device reference count leak (CVE-2022-48973 bsc#1232039)
- commit cbd0482
- Bluetooth: Fix not cleanup led when bt_init fails (CVE-2022-48971 bsc#1232037)
- commit ce6c97c
- cifs: Fix buffer overflow when parsing NFS reparse points
(bsc#1232089, CVE-2024-49996).
- commit 009c8ed
- netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() (CVE-2024-47685 bsc#1231998)
- commit 6b03439
- net: Fix an unsafe loop on the list (CVE-2024-50024 bsc#1231954)
- commit b3d8cae
- ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() (CVE-2024-47707 bsc#1231935)
- commit 4b59ef3
- mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() (CVE-2022-48972 bsc#1232025)
- commit 0168947
- HID: core: fix shift-out-of-bounds in hid_report_raw_event (CVE-2022-48978 bsc#1232038)
- commit 7a79be0
- netfilter: br_netfilter: fix panic with metadata_dst skb (CVE-2024-50045 bsc#1231903)
- commit 2c7a2ef
- block, bfq: fix possible UAF for bfqq->bic with merge chain (CVE-2024-47706 bsc#1231942)
- commit c8fc3bd
- tcp: check skb is non-NULL in tcp_rto_delta_us() (CVE-2024-47684 bsc#1231987)
- commit 3560609
- net: hsr: Fix potential use-after-free (CVE-2022-49015 bsc#1231938)
- commit 6ebc760
- ocfs2: cancel dqi_sync_work before freeing oinfo (bsc#1232141
CVE-2024-49966).
- commit b3c314a
- RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled (bsc#1232111 CVE-2024-47735)
- commit 78adc47
- ocfs2: reserve space for inline xattr before attaching reflink
tree (bsc#1232151 CVE-2024-49958).
- commit 75ba1c4
- wifi: mac80211: use two-phase skb reclamation in
ieee80211_do_stop() (CVE-2024-47713 bsc#1232016).
- commit 6ae0d21
- nfsd: call cache_put if xdr_reserve_space returns NULL
(bsc#1232056 CVE-2024-47737).
- commit 629ef18
- Update
patches.suse/memcg-Fix-possible-use-after-free-in-memcg_write_event_control.patch
(bsc#1206344, CVE-2022-48988, bsc#1232069).
- commit 3727547
- slip: make slhc_remember() more robust against malicious packets
(CVE-2024-50033 bsc#1231914).
- net: tun: Fix use-after-free in tun_detach() (CVE-2022-49014
bsc#1231890).
- commit c68baf4
- md/raid5: fix deadlock that raid5d() wait for itself to clear
MD_SB_CHANGE_PENDING (bsc#1227437, CVE-2024-39476).
- Delete the following patch, it is replaced by the above one,
patches.suse/Revert-md-raid5-Wait-for-MD_SB_CHANGE_PENDING-in-rai.patch.
- commit e9834f3
- net/ipv6: prevent use after free in ip6_route_mpath_notify
(CVE-2024-26852 bsc#1223057 bsc#1230784).
- Update
patches.suse/net-ipv6-avoid-possible-UAF-in-ip6_route_mpath_notif.patch
(CVE-2024-26852 bsc#1223057 bsc#1230784).
- commit 7d060a6
- drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds
write error (bsc#1231858 CVE-2024-47697).
- drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds
write error (bsc#1231859 CVE-2024-47698).
- commit d62c304
- ethtool: fail closed if we can't get max channel used in
indirection tables (CVE-2024-46834 bsc#1231096).
- commit bddfacf
- gpio: prevent potential speculation leaks in
gpio_device_get_desc() (stable-fixes CVE-2024-44931
bsc#1229837).
- commit 664410d
- gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
(stable-fixes CVE-2024-42253 bsc#1229005).
- commit 966ef70
- mm: avoid leaving partial pfn mappings around in error case
(CVE-2024-47674 bsc#1231673).
- commit b85f7d9
- udf: Avoid excessive partition lengths (bsc#1230773
CVE-2024-46777).
- fsnotify: clear PARENT_WATCHED flags lazily (bsc#1231439
CVE-2024-47660).
- commit 1cf833b
- netem: fix return value if duplicate enqueue fails
(CVE-2024-45016 bsc#1230429).
- net: netem: fix use after free and double free with packet
corruption (git-fixes CVE-2024-45016 bsc#1230429).
- net: netem: correct the parent's backlog when corrupted packet
was dropped (git-fixes CVE-2024-45016 bsc#1230429).
- net: netem: fix error path for corrupted GSO frames (git-fixes
CVE-2024-45016 bsc#1230429).
- net: netem: fix backlog accounting for corrupted GSO frames
(git-fixes CVE-2024-45016 bsc#1230429).
- commit 8535e0c
- perf/x86/intel: Limit the period on Haswell (bsc#1231072,
CVE-2024-46848).
- commit ddcb55d
- Update
patches.suse/ocfs2-add-bounds-checking-to-ocfs2_xattr_find_entry.patch
(bsc#1228410 CVE-2024-41016 CVE-2024-47670 bsc#1231537).
- commit 3c9794f
- wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
(CVE-2024-47673 bsc#1231539).
- commit ec71cef
- wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
(CVE-2024-47672 bsc#1231540).
- commit bf00ca5
- sched/smt: Fix unbalance sched_smt_present dec/inc
(CVE-2024-44958 bsc#1230179).
- commit d76ce7a
- add bug reference for a mana change (bsc#1229769).
- commit 365e607
- nfc: fix segfault in nfc_genl_dump_devices_done (CVE-2021-47612 bsc#1226585)
- commit 04d816c
- aoe: fix the potential use-after-free problem in more places
(bsc#1218562 CVE-2023-6270).
- commit 9a97d1d
- xhci: Fix null pointer dereference when host dies
(CVE-2023-52898 bsc#1229568).
- commit 8083a37
- bpf: Fix pointer-leak due to insufficient speculative store
bypass mitigation (bsc#1231375).
- commit 8169915
- wifi: mwifiex: Do not return unused priv in
mwifiex_get_priv_by_id() (bsc#1230802 CVE-2024-46755).
- commit 3faac0d
- Delete some more obsolete scripts
- commit c036565
- drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links (CVE-2024-46816 bsc#1231197).
- commit fce3225
- drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number (bsc#1230725 CVE-2024-46724)
- commit a6d26f5
- drm/amd/display: Check link_index before accessing dc->links (CVE-2024-46813 bsc#1231191).
- commit 6cd35ce
- rpm/release-projects: Add SLFO projects (bsc#1231293).
- commit 9f2c584
- Update kabi files from rpm-4.12.14-122.228
Some nvme symbols are listed as exported from vmlinux while the driver
is modular. This is because the symvers files were not updated after
making the driver modular.
- commit 00d2c7f
- ELF: fix kernel.randomize_va_space double read (CVE-2024-46826 bsc#1231115)
Dropped const and split declaration and assignment to avoid warning of
mixing declarations and statements.
- commit 8b66569
- drm/amd/display: added NULL check at start of dc_validate_stream (CVE-2024-46802 bsc#1231111)
- commit a598fc3
- Revert "Merge branch 'users/dwagner/SLE12-SP5/for-next' into SLE12-SP5"
This reverts commit aa4c39a920ecb484add5aa1733bbaa0fb81c7d46, reversing
changes made to 4527634da2625f9c0c83176368afe9fe8acb3ffc.
- --
Following breaks kABI:
commit 72d636029eff5515a118fd98f44689c4421a836e
Author: Daniel Wagner <dwagner@suse.de>
Date: Mon Sep 30 15:48:52 2024 +0200
kabi: ignore all nvme kabi breakages
Streamline sle12sp5 with the other code stream where we ignore
all symbol changes inside the nvme subsystem.
Delete:
- patches.kabi/kabi-Fix-nvme-fabrics_q.patch
- patches.kabi/kabi-Fix-nvmet-error-log-definitions.patch
- patches.kabi/kabi-nvme-fix-fast_io_fail_tmo.patch
- --
As designed the path match does not match symbols exported from vmlinux
(built-in), those have to be listed explicitly.
Listing the offending symbols should make this change work. It's
possible that more of the nvme support is modular on later kernels or
the kABI brekage is not as widespread compared to 4.12.
- ---
- commit 5f0ddca
- net: dpaa: Pad packets to ETH_ZLEN (CVE-2024-46854 bsc#1231084).
- ice: Add netif_device_attach/detach into PF reset flow
(CVE-2024-46770 bsc#1230763).
- net: core: Specify skb_pad()/skb_put_padto() SKB freeing
(CVE-2024-46854 bsc#1231084).
- commit 8314902
- usbnet: fix cyclical race on disconnect with work queue
(git-fixes).
- Refresh
patches.kabi/move-new-members-of-struct-usbnet-to-end.patch.
- Refresh
patches.suse/0002-Add-a-void-suse_kabi_padding-placeholder-to-some-USB.patch.
- commit d5af998
- powerpc/imc-pmu: Revert nest_init_lock to being a mutex
(bsc#1065729).
- commit 9d9f624
- powerpc/xmon: Fix disassembly CPU feature checks (bsc#1065729).
- powerpc/pseries: fix possible memory leak in ibmebus_bus_init()
(bsc#1065729).
- powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
(bsc#1054914 fate#322448 git-fixes).
- powerpc/iommu: Annotate nested lock for lockdep (bsc#1065729).
- commit 1b7c467
- Fix bsc#1054914 reference.
- commit 4b9db88
- nvme: avoid double free special payload (bsc#1228635
CVE-2024-41073).
- commit 50941e4
- ceph: remove the incorrect Fw reference check when dirtying
pages (bsc#1231184).
- commit 4527634
- rpm/check-for-config-changes: add HAVE_RUST and RUSTC_SUPPORTS_ to IGNORED_CONFIGS_RE
They depend on SHADOW_CALL_STACK.
- commit 65fa52b
- nvmet: always initialize cqe.result (bsc#1228615
CVE-2024-41079).
- commit 0c4e344
- kabi/severities: Ignore ppc instruction emulation (bsc#1230826 ltc#205848)
These are lowlevel functions not used outside of exception handling and
kernel debugging facilities.
- commit abc513a
- drm/amd/display: Check BIOS images before it is used (CVE-2024-46809 bsc#1231148).
- commit 006eae3
- platform/x86: panasonic-laptop: Fix SINF array out of bounds
accesses (CVE-2024-46859 bsc#1231089).
- commit 59d5c89
- spi: nxp-fspi: fix the KASAN report out-of-bounds bug
(CVE-2024-46853 bsc#1231083).
- commit bb10262
- media: vivid: fix compose size exceed boundary (CVE-2022-48945
bsc#1230398).
- commit 9b78931
- kthread: Fix task state in kthread worker if being frozen
(bsc#1231146).
- commit acf39f7
- kabi: ignore all nvme kabi breakages
Streamline sle12sp5 with the other code stream where we ignore
all symbol changes inside the nvme subsystem.
Delete:
- patches.kabi/kabi-Fix-nvme-fabrics_q.patch
- patches.kabi/kabi-Fix-nvmet-error-log-definitions.patch
- patches.kabi/kabi-nvme-fix-fast_io_fail_tmo.patch
- commit 72d6360
- nvme-fabrics: use reserved tag for reg read/write command
(bsc#1228620 CVE-2024-41082).
Refresh:
- patches.kabi/kabi-Fix-nvme-fabrics_q.patch
- nvme-fabrics: use reserved tag for reg read/write command
(bsc#1228620 CVE-2024-41082).
- nvme: change __nvme_submit_sync_cmd() calling conventions
(bsc#1228620 CVE-2024-41082).
- nvme: remove unused timeout parameter (bsc#1228620
CVE-2024-41082).
- nvme: split nvme_alloc_request() (bsc#1228620 CVE-2024-41082).
Refresh:
- patches.suse/lightnvm-remove-lightnvm-implemenation.patch
- nvme: centralize setting the timeout in nvme_alloc_request
(bsc#1228620 CVE-2024-41082).
Refresh:
- patches.suse/lightnvm-remove-lightnvm-implemenation.patch
- commit 1db4029
- tracing: Avoid possible softlockup in tracing_iter_reset()
(git-fixes).
- commit 6f4c555
- arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry (bsc#1231120 CVE-2024-46822)
- commit cd9816b
- arm64: acpi: Move get_cpu_for_acpi_id() to a header (bsc#1231120 CVE-2024-46822)
- commit 0c95f6d
- tracing: Fix overflow in get_free_elt() (git-fixes
CVE-2024-43890 bsc#1229764).
- commit 2519a16
- drm/amd/pm: fix the Out-of-bounds read warning (bsc#1230709 CVE-2024-46731)
- commit 1b11b68
- af_unix: Fix data races around sk->sk_shutdown (bsc#1226846).
- af_unix: annotate lockless accesses to sk->sk_err (bsc#1226846).
- commit 7b2aa7b
- drm/amdgpu: fix mc_data out-of-bounds read warning (CVE-2024-46722 bsc#1230712)
- commit 7ff2284
- i2c: lpi2c: Avoid calling clk_get_rate during transfer
(bsc#1227885 CVE-2024-40965).
- commit 115f782
- Update
patches.suse/fuse-Initialize-beyond-EOF-page-contents-before-setti.patch
(bsc#1229457 CVE-2024-44947 bsc#1229456).
- Update
patches.suse/msft-hv-3046-uio_hv_generic-Fix-kernel-NULL-pointer-dereference-i.patch
(git-fixes CVE-2024-46739 bsc#1230732).
- Update
patches.suse/msft-hv-3048-net-mana-Fix-error-handling-in-mana_create_txq-rxq-s.patch
(git-fixes CVE-2024-46784 bsc#1230771).
- Update
patches.suse/nvmet-tcp-fix-kernel-crash-if-commands-allocation-fa.patch
(git-fixes CVE-2024-46737 bsc#1230730).
- Update
patches.suse/powerpc-rtas-Prevent-Spectre-v1-gadget-construction-.patch
(bsc#1227487 CVE-2024-46774 bsc#1230767).
- commit ad5a546
- userfaultfd: fix checks for huge PMDs (CVE-2024-46787
bsc#1230815).
- commit a5d0a66
- PCI: xilinx-nwl: Clean up clock on probe failure/removal
(git-fixes).
- commit ace75db
- net: ip_tunnel: prevent perpetual headroom growth
(CVE-2024-26804 bsc#1222629).
- commit 7a0d3d3
- net: tunnels: annotate lockless accesses to dev->needed_headroom
(CVE-2024-26804 bsc#1222629).
- Refresh
patches.kabi/kabi-preserve-struct-header_ops-after-bsc-1176081-fi.patch.
- commit 4908ccc
- kabi: add __nf_queue_get_refs() for kabi compliance
(bsc#1229633,CVE-2022-48911).
- commit ffffe4c
- netfilter: nf_queue: fix possible use-after-free (bsc#1229633,
CVE-2022-48911).
- commit c9290c8
- RDMA/cxgb4: Added NULL check for lookup_atid (git-fixes)
- commit a4946ef
- RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency (git-fixes)
- commit 4ef1336
- RDMA/core: Remove unused declaration rdma_resolve_ip_route() (git-fixes)
- commit 7580f3e
- kABI fix for tipc: wait and exit until all work queues are done
(CVE-2021-47163 bsc#1221980).
- commit 685278e
- tipc: wait and exit until all work queues are done
(CVE-2021-47163 bsc#1221980).
- commit 60b5a40
- btrfs: handle errors from btrfs_dec_ref() properly (CVE-2024-46753 bsc#1230796)
- commit ab888f1
- net: bridge: xmit: make sure we have at least eth header len
bytes (CVE-2024-38538 bsc#1226606).
- commit 37ef8fc
- x86/kaslr: Expose and use the end of the physical memory
address space (bsc#1230405).
- commit 151c0a3
- Delete
patches.suse/cifs-fix-double-free-race-when-mount-fails-in-cifs_get_root-.patch.
This patch should have been only in kernel v5.11+, which is when
the double free issue was introduced.
- commit 92bb491
- pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv (CVE-2024-46761 bsc#1230761)
- commit 0c20c64
- hwmon: (adc128d818) Fix underflows seen when writing limit attributes (CVE-2024-46759 bsc#1230814)
- commit 8ed41b4
- Input: uinput - reject requests with unreasonable number of slots (CVE-2024-46745 bsc#1230748)
- commit 9508651
- VMCI: Fix use-after-free when removing resource in vmci_resource_remove() (CVE-2024-46738 bsc#1230731)
- commit 98e87d9
- tcp_bpf: fix return value of tcp_bpf_sendmsg() (CVE-2024-46783 bsc#1230810)
- commit f6705ba
- Update references in patches.suse/nvmet-tcp-fix-kernel-crash-if-commands-allocation-fa.patch (CVE-2024-46737 bsc#1230730)
- commit 91952f9
- nvmet: Identify-Active Namespace ID List command should reject
invalid nsid (git-fixes).
- nvmet-tcp: fix kernel crash if commands allocation fails
(git-fixes).
- commit 07a5a05
- net: fix use-after-free in tw_timer_handler (CVE-2021-46936
bsc#1220439).
- commit b2028df
- drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails (CVE-2024-44982 bsc#1230204).
- commit 4f660ab
- drm/amdgpu: fix ucode out-of-bounds read warning (bsc#1230702 CVE-2024-46723)
- commit ff45869
- Update
patches.suse/nfc-nci-Fix-uninit-value-in-nci_rx_work.patch
(git-fixes CVE-2024-38381 bsc#1226878).
- Update
patches.suse/vfio-pci-fix-potential-memory-leak-in-vfio_intx_enab.patch
(git-fixes CVE-2024-38632 bsc#1226860).
Add CVE references.
- commit bd6ac3f
- PCI: Add missing bridge lock to pci_bus_lock() (CVE-2024-46750
bsc#1230783).
- commit 6d64b3d
- Squashfs: sanity check symbolic link size (bsc#1230747 CVE-2024-46744)
- commit 067cd70
- ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
(git-fixes).
- commit 36cf250
- ocfs2: remove unreasonable unlock in ocfs2_read_blocks
(git-fixes).
- commit 13d7dfe
- ocfs2: fix null-ptr-deref when journal load failed (git-fixes).
- commit 4386caf
- powerpc/ppc-opcode: Add divde and divdeu opcodes (bsc#1230826
ltc#205848).
- powerpc/lib/sstep: Add XER bits introduced in POWER ISA v3.0
(bsc#1230826 ltc#205848).
- commit 4de0867
- of/irq: Prevent device address out-of-bounds read in interrupt
map walk (CVE-2024-46743 bsc#1230756).
- commit 8403759
- driver: iio: add missing checks on iio_info's callback access
(CVE-2024-46715 bsc#1230700).
- commit f7336e3
- pinctrl: single: fix potential NULL dereference in pcs_get_function() (CVE-2024-46685 bsc#1230515)
- commit e892b22
- usb: dwc3: core: Prevent USB core invalid event buffer address access (CVE-2024-46675 bsc#1230533)
- commit 9657973
- thunderbolt: Mark XDomain as unplugged when router is removed (CVE-2024-46702 bsc#1230589)
- commit 74749bb
- smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() (CVE-2024-46686 bsc#1230517)
- commit 9cca3e0
- scsi: aacraid: Fix double-free on probe failure (CVE-2024-46673 bsc#1230506)
- commit b132ff0
- apparmor: fix possible NULL pointer dereference (CVE-2024-46721 bsc#1230710)
- commit 2b27b0b
- gtp: fix a potential NULL pointer dereference (CVE-2024-46677 bsc#1230549)
- commit b3221e1
- nfc: pn533: Add poll mod list filling check (CVE-2024-46676 bsc#1230535)
- commit 0ff9f28
- ethtool: check device is present when getting link settings (CVE-2024-46679 bsc#1230556).
- commit 34a40a8
- powerpc/sstep: Fix darn emulation (bsc#1230826 ltc#205848).
- powerpc/sstep: Fix incorrect return from analyze_instr()
(bsc#1230826 ltc#205848).
- commit be8f831
- powerpc/lib/sstep: Fix 'sthcx' instruction (bsc#1230826
ltc#205848).
- powerpc/lib/sstep: fix 'ptesync' build error (bsc#1230826
ltc#205848).
- powerpc/sstep: Check instruction validity against ISA version
before emulation (bsc#1230826 ltc#205848).
- powerpc/fpu: Drop cvt_fd() and cvt_df() (bsc#1230826
ltc#205848).
- Refresh patches.suse/powerpc-Don-t-clobber-f0-vs0-during-fp-altivec-regis.patch
- powerpc/sstep: Add support for divde[.] and
divdeu[.] instructions (bsc#1230826 ltc#205848).
- powerpc/lib: fix redundant inclusion of quad.o (bsc#1230826
ltc#205848).
- powerpc sstep: Add support for modsd, modud instructions
(bsc#1230826 ltc#205848).
- powerpc sstep: Add support for modsw, moduw instructions
(bsc#1230826 ltc#205848).
- powerpc sstep: Add support for extswsli instruction (bsc#1230826
ltc#205848).
- powerpc sstep: Add support for cnttzw, cnttzd instructions
(bsc#1230826 ltc#205848).
- powerpc: sstep: Add support for darn instruction (bsc#1230826
ltc#205848).
- powerpc: sstep: Add support for maddhd, maddhdu, maddld
instructions (bsc#1230826 ltc#205848).
- Refresh patches.suse/powerpc-bpf-use-unsigned-division-instruction-for-64.patch
- powerpc/sstep: Fix kernel crash if VSX is not present
(bsc#1230826 ltc#205848).
- powerpc/sstep: Introduce GETTYPE macro (bsc#1230826 ltc#205848).
- powerpc/lib: Fix "integer constant is too large" build failure
(bsc#1230826 ltc#205848).
- powerpc/32: Move the inline keyword at the beginning of function
declaration (bsc#1230826 ltc#205848).
- powerpc/kprobes: Blacklist emulate_update_regs() from kprobes
(bsc#1230826 ltc#205848).
- powerpc/lib/sstep: Fix fixed-point shift instructions that
set CA32 (bsc#1230826 ltc#205848).
- powerpc/lib/sstep: Fix fixed-point arithmetic instructions
that set CA32 (bsc#1230826 ltc#205848).
- powerpc/kprobes: Update optprobes to use emulate_update_regs()
(bsc#1230826 ltc#205848).
- powerpc: Fix handling of alignment interrupt on dcbz instruction
(bsc#1230826 ltc#205848).
- powerpc: Fix kernel crash in emulation of vector loads and
stores (bsc#1230826 ltc#205848).
- commit 41c7998
- md/raid5: avoid BUG_ON() while continue reshape after
reassembling (bsc#1229790, CVE-2024-43914).
- commit 2925547
- powerpc/lib/sstep: Fix count leading zeros instructions
(bsc#1230826 ltc#205848).
- powerpc/sstep: mullw should calculate a 64 bit signed result
(bsc#1230826 ltc#205848).
- powerpc/sstep: Fix issues with mcrf (bsc#1230826 ltc#205848).
- powerpc/sstep: Fix issues with set_cr0() (bsc#1230826
ltc#205848).
- powerpc/sstep: Avoid used uninitialized error (bsc#1230826
ltc#205848).
- powerpc: Wrap register number correctly for string load/store
instructions (bsc#1230826 ltc#205848).
- powerpc: Emulate load/store floating point as integer word
instructions (bsc#1230826 ltc#205848).
- powerpc: Use instruction emulation infrastructure to handle
alignment faults (bsc#1230826 ltc#205848).
- Refresh patches.suse/powerpc-Fix-check-for-copy-paste-instructions-in-ali.patch
- Update config files.
- powerpc: Separate out load/store emulation into its own function
(bsc#1230826 ltc#205848).
- powerpc: Handle opposite-endian processes in emulation code
(bsc#1230826 ltc#205848).
- powerpc: Set regs->dar if memory access fails in emulate_step()
(bsc#1230826 ltc#205848).
- powerpc: Emulate the dcbz instruction (bsc#1230826 ltc#205848).
- powerpc: Emulate load/store floating double pair instructions
(bsc#1230826 ltc#205848).
- powerpc: Emulate vector element load/store instructions
(bsc#1230826 ltc#205848).
- powerpc: Emulate FP/vector/VSX loads/stores correctly when
regs not live (bsc#1230826 ltc#205848).
- powerpc: Make load/store emulation use larger memory accesses
(bsc#1230826 ltc#205848).
- powerpc: Add emulation for the addpcis instruction (bsc#1230826
ltc#205848).
- powerpc: Don't update CR0 in emulation of popcnt, prty, bpermd
instructions (bsc#1230826 ltc#205848).
- powerpc: Fix emulation of the isel instruction (bsc#1230826
ltc#205848).
- powerpc/64: Fix update forms of loads and stores to write
64-bit EA (bsc#1230826 ltc#205848).
- powerpc: Handle most loads and stores in instruction emulation
code (bsc#1230826 ltc#205848).
- powerpc: Don't check MSR FP/VMX/VSX enable bits in
analyse_instr() (bsc#1230826 ltc#205848).
- powerpc: Change analyse_instr so it doesn't modify *regs
(bsc#1230826 ltc#205848).
- powerpc/lib/sstep: Add isel instruction emulation (bsc#1230826
ltc#205848).
- powerpc/lib/sstep: Add prty instruction emulation (bsc#1230826
ltc#205848).
- powerpc/lib/sstep: Add bpermd instruction emulation (bsc#1230826
ltc#205848).
- powerpc/lib/sstep: Add popcnt instruction emulation (bsc#1230826
ltc#205848).
- powerpc/lib/sstep: Add cmpb instruction emulation (bsc#1230826
ltc#205848).
- commit 10b1c67
- KABI: kcm: Serialise kcm_sendmsg() for the same socket
(CVE-2024-44946 bsc#1230015).
- commit 7a83511
- kcm: Serialise kcm_sendmsg() for the same socket
(CVE-2024-44946 bsc#1230015).
- commit a7c5ad6
- KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
(CVE-2024-46707 bsc#1230582).
- commit a6e55a2
- perf: Fix list corruption in perf_cgroup_switch() (bsc#1227953
CVE-2022-48799).
- commit 7c98d1e
- nvme-tcp: fix possible use-after-free in transport
error_recovery work (bsc#1228000 (CVE-2022-48789)).
- nvme: fix a possible use-after-free in controller reset during
load (bsc#1227941 (CVE-2022-48790)).
- commit 699f243
- x86/mtrr: Check if fixed MTRRs exist before saving them (bsc#1230174 CVE-2024-44948).
- commit c14b9b5
- nvme-rdma: fix possible use-after-free in transport
error_recovery work (bsc#1227952 (CVE-2022-48788)).
- commit 0f2b472
- Input: MT - limit max slots (CVE-2024-45008 bsc#1230248).
- commit 18c0fe4
- Refresh
patches.suse/media-cec-core-avoid-confusing-transmit-timed-out-me.patch.
Moved into sorted section to avoid false positives of the checker
- commit 6e68152
- media: vivid: avoid integer overflow (git-fixes).
- commit 2e17cad
- netlink: extend policy range validation
(prerequisite CVE-2024-42114 bsc#1228564).
- Refresh patches.kabi/netlink-nla_policy-kabi-workaround.patch.
- commit 1f2aeb8
- media: vivid: dev->bitmap_cap wasn't freed in all cases
(git-fixes).
- commit 249a367
- media: vivid: s_fbuf: add more sanity checks (git-fixes).
- commit de48b55
- media: vivid: fix assignment of dev->fbuf_out_flags (git-fixes).
- commit 0c654cd
- ipv6: prevent UAF in ip6_send_skb() (CVE-2024-44987 bsc#1230185)
- commit a6345f7
- gtp: pull network headers in gtp_dev_xmit() (CVE-2024-44999 bsc#1230233)
- commit 6133ce9
- powerpc: Remove support for PowerPC 601 (Remove unused and
malformed assembly causing build error).
- commit a186115
- Drivers: hv: vmbus: Fix rescind handling in uio_hv_generic
(git-fixes).
- uio_hv_generic: Fix kernel NULL pointer dereference in
hv_uio_rescind (git-fixes).
- net: mana: Fix error handling in mana_create_txq/rxq's NAPI
cleanup (git-fixes).
- net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response
(git-fixes).
- commit 2c432a7
- profiling: fix shift too large makes kernel panic (git-fixes).
- commit 92e9109
- KVM: x86/mmu: make apf token non-zero to fix bug (CVE-2022-48943
bsc#1229645).
- commit 20aabb8
- media: dvb-usb-v2: af9035: fix missing unlock (CVE-2023-52915
bsc#1230270).
- commit 48622c6
- media: dvb-usb-v2: af9035: Fix null-ptr-deref in
af9035_i2c_master_xfer (CVE-2023-52915 bsc#1230270).
- commit a6997db
- usbnet: modern method to get random MAC (git-fixes).
- commit 26fa49e
- net: usb: sr9700: fix uninitialized variable use in sr_mdio_read
(git-fixes).
- commit f6a8914
- ACPI: EC: Avoid printing confusing messages in acpi_ec_setup()
(git-fixes).
- ACPI: EC: tweak naming in preparation for GpioInt support
(git-fixes).
- ACPI / EC: Clean up EC GPE mask flag (git-fixes).
- ACPI: EC: Fix an EC event IRQ storming issue (git-fixes).
- commit 9e80cf5
- Bluetooth: hci_core: Fix leaking sent_cmd skb (CVE-2022-48844 bsc#1228068)
- commit 33c7b67
- wifi: nl80211: disallow setting special AP channel widths (CVE-2024-43912 bsc#1229830)
- commit 3f6faef
- scsi: pm8001: Fix use-after-free for aborted TMF sas_task (CVE-2022-48791 bsc#1228002)
- commit 0f736ca
- scsi: pm80xx: Fix TMF task completion race condition (CVE-2022-48791 bsc#1228002)
- commit 47ce134
- ext4: sanity check for NULL pointer after ext4_force_shutdown
(bsc#1229753 CVE-2024-43898).
- commit d2ce48d
- udf: Avoid using corrupted block bitmap buffer (bsc#1229362
CVE-2024-42306).
- commit e9fe84a
- ext4: check dot and dotdot of dx_root before making dir indexed
(bsc#1229363 CVE-2024-42305).
- commit 1e9d591
- protect the fetch of ->fd[fd] in do_dup2() from mispredictions
(bsc#1229334 CVE-2024-42265).
- commit 126ef02
- ACPI: video: Add new hw_changes_brightness quirk, set it on
PB Easynote MZ35 (git-fixes).
- ACPI: blacklist: fix clang warning for unused DMI table
(git-fixes).
- Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk"
(git-fixes).
- ACPI: SPCR: Consider baud rate 0 as preconfigured state
(git-fixes).
- ACPI: SPCR: work around clock issue on xgene UART (git-fixes).
- commit 18ef221
- ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment
errata (git-fixes).
- Refresh
patches.suse/0001-tty-pl011-fix-initialization-order-of-QDF2400-E44.patch.
- commit 0985189
- serial: sc16is7xx: fix invalid FIFO access with special register
set (CVE-2024-44950 bsc#1230180).
- commit b162aad
- kabi fix for proc/mounts: add cursor (bsc#1207341).
- commit 1fada3d
- proc/mounts: add cursor (bsc#1207341).
- autofs4: use wait_event_killable (bsc#1207341).
- commit 1adc77e
- ALSA: line6: Fix racy access to midibuf (CVE-2024-44954
bsc#1230176).
- commit 899798d
- atm: idt77252: prevent use after free in dequeue_rx()
(CVE-2024-44998 bsc#1230171).
- driver core: Fix uevent_show() vs driver detach race
(CVE-2024-44952 bsc#1230178).
- commit c758c1a
- cpufreq: schedutil: Destroy mutex before kobject_put() frees the memory (CVE-2021-47387 bsc#1225316)
- commit ce3e04b
- s390/sclp: Prevent release of buffer in I/O (bsc#1230200
CVE-2024-44969 git-fixes).
- commit 495f327
- wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
(CVE-2024-42114 bsc#1228564).
Refresh patches.kabi/netlink-nla_policy-kabi-workaround.patch.
- commit 9abf38c
- fuse: use unsigned type for getxattr/listxattr size truncation
(bsc#1230151).
- commit 3543834
- Bluetooth: L2CAP: Fix not validating setsockopt user input
(bsc#1224579 CVE-2024-35965).
- commit 6d78576
- Bluetooth: L2CAP: Fix deadlock (git-fixes).
- commit 6afc15c
- Bluetooth: btintel: Fixe build regression (bsc#1224640
CVE-2024-35933).
- commit 67f9898
- Bluetooth: btintel: Fix null ptr deref in btintel_read_version
(bsc#1224640 CVE-2024-35933).
- commit 8955b3c
- usb: vhci-hcd: Do not drop references before new references
are gained (CVE-2024-43883 bsc#1229707).
- commit 1ab205e
- bluetooth/l2cap: sync sock recv cb and release (bsc#1228576
CVE-2024-41062).
- commit 7294061
- drm/i915/gem: Fix Virtual Memory mapping boundaries calculation (bsc#1229156 CVE-2024-42259)
- commit ad9c138
- net: usb: qmi_wwan: fix memory leak for not ip packets
(CVE-2024-43861 bsc#1229500).
- commit 706ebe0
- drm/vmwgfx: Fix a deadlock in dma buf fence polling (bsc#1229497 CVE-2024-43863)
- commit 3f53b56
- xfs: fix getfsmap reporting past the last rt extent (git-fixes).
- commit a9800d1
- xfs: fix uninitialized variable access (git-fixes).
- commit 3f7682d
- xfs: Fix the owner setting issue for rmap query in xfs fsmap
(git-fixes).
- commit f1b3405
- Update
patches.suse/0001-usb-xhci-Check-endpoint-is-valid-before-dereferencin.patch
(git-fixes CVE-2023-52901 bsc#1229531).
- Update
patches.suse/CDC-NCM-avoid-overflow-in-sanity-checking.patch
(git-fixes CVE-2022-48938 bsc#1229664).
- Update
patches.suse/RDMA-cma-Do-not-change-route.addr.src_addr-outside-s.patch
(bsc#1210629 CVE-2023-2176 CVE-2022-48925 bsc#1229630).
- Update patches.suse/RDMA-ib_srp-Fix-a-deadlock.patch (git-fixes
CVE-2022-48930 bsc#1229624).
- Update
patches.suse/cgroup-cpuset-Prevent-UAF-in-proc_cpuset_show.patch
(bsc#1228801 CVE-2024-43853 bsc#1229292).
- Update
patches.suse/cifs-fix-double-free-race-when-mount-fails-in-cifs_get_root-.patch
(bsc#1190317 CVE-2022-48919 bsc#1229657).
- Update
patches.suse/configfs-fix-a-race-in-configfs_-un-register_subsystem.patch
(git-fixes CVE-2022-48931 bsc#1229623).
- Update patches.suse/drm-virtio-Fix-GEM-handle-creation-UAF.patch
(git-fixes CVE-2022-48899 bsc#1229536).
- Update
patches.suse/ibmvnic-free-reset-work-item-when-flushing.patch
(bsc#1196516 ltc#196391 CVE-2022-48905 bsc#1229604).
- Update patches.suse/ixgbe-fix-pci-device-refcount-leak.patch
(git-fixes CVE-2022-48896 bsc#1229540).
- Update
patches.suse/memcg-protect-concurrent-access-to-mem_cgroup_idr.patch
(git-fixes CVE-2024-43892 bsc#1229761).
- Update
patches.suse/scsi-qla2xxx-Complete-command-early-within-lock.patch
(bsc#1228850 CVE-2024-42287 bsc#1229392).
- Update
patches.suse/scsi-qla2xxx-During-vport-delete-send-async-logout-e.patch
(bsc#1228850 CVE-2024-42289 bsc#1229399).
- Update
patches.suse/scsi-qla2xxx-Fix-for-possible-memory-corruption.patch
(bsc#1228850 CVE-2024-42288 bsc#1229398).
- Update
patches.suse/scsi-qla2xxx-validate-nvme_local_port-correctly.patch
(bsc#1228850 CVE-2024-42286 bsc#1229395).
- commit d202e91
- ata: libata-core: Fix double free on error
(CVE-2024-41087,bsc#1228466).
- commit bdef5f8
- drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules (CVE-2024-43907 bsc#1229787).
- commit 95a59bd
- drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr (CVE-2024-43905 bsc#1229784).
- commit 93f42ad
- serial: core: check uartclk for zero to avoid divide by zero
(bsc#1229759 CVE-2024-43893).
- commit 150a54e
- media: xc2028: avoid use-after-free in load_firmware_cb()
(CVE-2024-43900 bsc#1229756).
- commit 764489c
- Revert "irqdomain: Fixed unbalanced fwnode get and put (git-fixes)."
(bsc#1229851)
This reverts commit 37becc871554a4057226a862be812b4c0ff8c711 as it
breaks irqs on 12sp5. The patch is actually wrong in 12sp5. of_node is
refcounted here, not fwnode. So revert the patch without replacement.
- commit c53dc2f
- drm/amd/display: Add null checker before passing variables (CVE-2024-43902 bsc#1229767).
- commit 1c0c16f
- Bluetooth: MGMT: Add error handling to pair_device() (CVE-2024-43884 bsc#1229739)
- commit ecb471c
- btrfs: get rid of warning on transaction commit when using
flushoncommit (bsc#1229658 CVE-2022-48920).
- commit 2ac5fdc
- vfio/pci: fix potential memory leak in vfio_intx_enable()
(git-fixes).
- commit f6c36eb
- kABI: vfio: struct virqfd kABI workaround (CVE-2024-26812
bsc#1222808).
- commit 202caf3
- exec: Fix ToCToU between perm check and set-uid/gid usage
(CVE-2024-43882 bsc#1229503).
- commit 236a83a
- vfio: Introduce interface to flush virqfd inject workqueue
(bsc#1222808 CVE-2024-26812).
- commit 71f96a8
- vfio/pci: Create persistent INTx handler (bsc#1222808
CVE-2024-26812).
- commit 26ca5db
- ip6_tunnel: Fix broken GRO (bsc#1226323).
- net/mlx5: Always drain health in shutdown callback
(CVE-2024-43866 bsc#1229495).
- commit d1b0995
- net: ipv6: ensure we call ipv6_mc_down() at most once (CVE-2022-48910 bsc#1229632)
- commit 80d1e79
- gsmi: fix null-deref in gsmi_get_variable (CVE-2023-52893 bsc#1229535)
- commit 0d2fd7b
- Fix reference in patches.suse/netfilter-tproxy-bail-out-if-IP-has-been-disabled-on.patch (CVE-2024-36270 bsc#1226798)
- commit 705c30b
- s390/pkey: Wipe copies of protected- and secure-keys
(CVE-2024-42155 bsc#1228733).
- commit 1712d5c
- nfc: pn533: initialize struct pn533_out_arg properly
(CVE-2022-48875 bsc#1229516).
- commit 3dc4ecc
- nfc: pn533: Wait for out_urb's completion in
pn533_usb_send_frame() (CVE-2023-52907 bsc#1229526).
- commit 462fb2b
- wifi: mac80211: sdata can be NULL during AMPDU start
(CVE-2022-48875 bsc#1229516).
- commit 5fb2170
- devres: Fix memory leakage caused by driver API devm_free_percpu() (CVE-2024-43871 bsc#1229490)
- commit 4465aef
- rpm/check-for-config-changes: Exclude ARCH_USING_PATCHABLE_FUNCTION_ENTRY
gcc version dependent, at least on ppc
- commit 16da158
- s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
(CVE-2024-42158 bsc#1228720).
- commit 13ea3b5
- af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
(bsc#1226846 CVE-2024-38596).
- Update
patches.suse/af_unix-Fix-data-races-around-sk-sk_shutdown.patch
(git-fixes bsc#1226846).
- commit a35b43b
- RDMA/hns: Fix soft lockup under heavy CEQE load (bsc#1229489 CVE-2024-43872)
- commit 8bd84db
- ipv6: sr: fix memleak in seg6_hmac_init_algo (CVE-2024-39489 bsc#1227623)
- commit 9c4fab9
- usb: xhci: prevent potential failure in handle_tx_event()
for Transfer events without TRB (CVE-2024-42226 bsc#1228709).
- commit e6525c1
- usb: gadget: configfs: Prevent OOB read/write in
usb_string_copy() (CVE-2024-42236 bsc#1228964).
- commit bf495b3
- USB: serial: mos7840: fix crash on resume (CVE-2024-42244
bsc#1228967).
- commit c904d0e
- wifi: cfg80211: handle 2x996 RU allocation in
cfg80211_calculate_bitrate_he() (CVE-2024-43879 bsc#1229482).
- commit 8fe6121
- kABI: tpm-interface: Hide new include from genksyms
(bsc#1082555).
- commit d46dd8a
- cpufreq: schedutil: Use kobject release() method to free sugov_tunables (CVE-2021-47387 bsc#1225316)
CVE backport so remove it from blacklist.conf, added in 56273cd113da0c
("blacklist.conf: Fix to experimental feature, fix only in the event of
a customer bug").
- commit 074afac
- netfilter: nf_tables: fix memleak in map from abort path
(CVE-2024-27011 bsc#1223803).
- commit 5b46784
- Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
(bsc#1225578 CVE-2024-36013).
- commit 12a50ad
- filelock: Fix fcntl/close race recovery compat path (bsc#1228427
CVE-2024-41020).
- commit 0ef50b1
- filelock: Remove locks reliably when fcntl/close race is
detected (bsc#1228247 CVE-2024-41012).
- commit c84976c
- netfilter: nft_limit: reject configurations that cause integer
overflow (CVE-2024-26668 bsc#1222335).
- commit 0c4fd3e
- netfilter: nft_limit: fix packet ratelimiting (CVE-2024-26668
bsc#1222335).
- Refresh
patches.suse/netfilter-nft_limit-avoid-possible-divide-error-in-n.patch.
- commit 045f275
- kvm: s390: Reject memory region operations for ucontrol VMs
(CVE-2024-43819 bsc#1229290 git-fixes).
- commit e43e818
- s390/pkey: Wipe sensitive data on failure (CVE-2024-42157
bsc#1228727 git-fixes).
- commit 323dd0d
- irqdomain: Fixed unbalanced fwnode get and put (git-fixes).
- genirq/generic_chip: Make irq_remove_generic_chip() irqdomain
aware (git-fixes).
- genirq/ipi: Fix NULL pointer deref in
irq_data_get_affinity_mask() (git-fixes).
- irqdomain: Fix domain registration race (git-fixes).
- irqdomain: Fix mapping-creation race (git-fixes).
- irqdomain: Refactor __irq_domain_alloc_irqs() (git-fixes).
- irqdomain: Look for existing mapping only once (git-fixes).
- irqdomain: Drop bogus fwspec-mapping error handling (git-fixes).
- irqdomain: Fix association race (git-fixes).
- genirq/irqdesc: Don't try to remove non-existing sysfs files
(git-fixes).
- genirq/msi: Ensure deactivation on teardown (git-fixes).
- genirq/msi: Activate Multi-MSI early when
MSI_FLAG_ACTIVATE_EARLY is set (git-fixes).
- genirq/irqdomain: Check pointer in
irq_domain_alloc_irqs_hierarchy() (git-fixes).
- genirq/proc: Reject invalid affinity masks (again) (git-fixes).
- genirq: Delay deactivation in free_irq() (git-fixes).
- kABI: genirq: Delay deactivation in free_irq() (kabi git-fixes).
- genirq: Make sure the initial affinity is not empty (git-fixes).
- commit 37becc8
- KVM: mmio: Fix use-after-free Read in
kvm_vm_ioctl_unregister_coalesced_mmio (CVE-2021-47341
bsc#1224923).
- commit 12d646d
- bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
(CVE-2024-43839 bsc#1229301).
- commit 5a42d4e
- efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
(bsc#1226629 CVE-2022-48769).
- commit 88b4118
- dma: fix call order in dmam_free_coherent (bsc#1229346
CVE-2024-43856).
- commit b96a5fb
- netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() (CVE-2024-36286 bsc#1226801)
- commit 3ee11b6
- netfilter: tproxy: bail out if IP has been disabled on the device (CVE-2024-36270 1226798)
- commit d5e958c
- netfilter: nf_conntrack_h323: Add protection for bmp length out of range (CVE-2024-26851 bsc#1223074)
Previous four patches fix other bound check bugs or prepare code for
this to apply cleanly.
- commit ca9c856
- netfilter: nf_conntrack_h323: restore boundary check correctness (bsc#1223074)
- commit a87a86d
- netfilter: nf_ct_h323: Extend nf_h323_error_boundary to work on bits as well (bsc#1223074)
- commit 034ab36
- netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function (bsc#1223074)
- commit f812de4
- netfilter: nf_ct_h323: Out Of Bound Read in Netfilter Conntrack (bsc#1223074)
- commit b7e85f6
- ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your
kernel is fine." (bsc#1227820 CVE-2024-40984).
- commit cc6eb03
- scsi: target: core: Silence the message about unknown VPD pages
(bsc#1221252 bsc#1229462).
- commit 73ee6e7
- mISDN: Fix a use after free in hfcmulti_tx() (CVE-2024-42280 bsc#1229388)
- commit e5565c3
- tipc: Return non-zero value from tipc_udp_addr2str() on error (CVE-2024-42284 bsc#1229382)
- commit 4d8536f
- sysctl: always initialize i_uid/i_gid (CVE-2024-42312 bsc#1229357)
- commit b5674a1
- drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes (CVE-2024-42310 bsc#1229358)
- commit ac17234
- drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes (CVE-2024-42309 bsc#1229359)
- commit 452c306
- block: initialize integrity buffer to zero before writing it to media (CVE-2024-43854 bsc#1229345)
- commit 2414013
- ipvs: properly dereference pe in ip_vs_add_service (CVE-2024-42322 bsc#1229347)
- commit 3e24abe
- dev/parport: fix the array out-of-bounds risk (CVE-2024-42301
bsc#1229407).
- commit b4a682d
- RDMA/iwcm: Fix a use-after-free related to destroying CM IDs (bsc#1229381 CVE-2024-42285)
- commit b6331d8
- arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to (git-fixes)
- commit c501ca8
- media: mediatek: vcodec: Handle invalid decoder vsi
(CVE-2024-43831 bsc#1229309).
- commit 38f48e2
- fuse: Initialize beyond-EOF page contents before setting
uptodate (bsc#1229457).
- commit 7188cb3
- bpf: Fix a segment issue when downgrading gso_size (bsc#1229386
CVE-2024-42281).
- commit 4edf813
- Refresh
patches.suse/bpf-fix-bpf_skb_adjust_net-bpf_skb_proto_xlat-to-dea.patch.
- add hunks that were missing because this patch predates
patches.suse/bpf-add-bpf_skb_adjust_room-helper.patch
- commit b6ecdd7
- net/iucv: fix use after free in iucv_sock_close()
(CVE-2024-42271 bsc#1229400 bsc#1228975).
- commit f2f712f
- Refresh sorted patches.
- Refresh patches.suse/cpu-SMT-Enable-SMT-only-if-a-core-is-online.patch.
- Refresh patches.suse/powerpc-topology-Check-if-a-core-is-online.patch.
- commit 1b405bb
- Update patches.suse/cpu-SMT-Enable-SMT-only-if-a-core-is-online.patch
(bsc#1214285 bsc#1205462 ltc#200161 ltc#200588 git-fixes
bsc#1229327 ltc#206365).
- Update patches.suse/powerpc-topology-Check-if-a-core-is-online.patch
(bsc#1214285 bsc#1205462 ltc#200161 ltc#200588 git-fixes
bsc#1229327 ltc#206365).
- commit a8be45e
- gss_krb5: Fix the error handling path for
crypto_sync_skcipher_setkey (git-fixes).
- commit 6e52103
- ALSA: timer: Relax start tick time check for slave timer
elements (git-fixes CVE-2024-38618 bsc#1226754).
- commit de27c4e
- USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor (CVE-2024-41035 bsc#1228485)
- commit 456ee09
- s390/uv: Panic for set and remove shared access UVC errors
(git-fixes bsc#1229229).
- commit 172448f
- gve: Account for stopped queues when reading NIC stats
(CVE-2024-42162 bsc#1228706).
- commit 7acbc65
- net: mana: Fix race on per-CQ variable napi work_done
(bsc#1229154).
- Refresh
patches.suse/net-mana-Configure-hwc-timeout-from-hardware.patch.
- commit d7d72be
- net: mana: Fix doorbell out of order violation and avoid
unnecessary doorbell rings (bsc#1229154).
- commit 72d0bd1
- KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
(git-fixes bsc#1229222).
- commit 590a719
- mmc: mmc_spi: fix error handling in mmc_spi_probe() (bsc#1225483
CVE-2023-52708).
- commit c7ef14e
- sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl
(bsc#1225508 CVE-2021-47549).
- commit ed3ad9e
- irqchip/gic-v3-its: Fix potential VPE leak on error (bsc#1225190
CVE-2021-47373).
- commit c95f6d5
- i2c: acpi: fix resource leak in reconfiguration device addition
(bsc#1225223 CVE-2021-47425).
- commit 61ff581
- nfc: nci: Fix handling of zero-length payload packets in
nci_rx_work() (git-fixes).
- nfc: nci: Fix uninit-value in nci_rx_work (git-fixes).
- nfc: nci: Fix kcov check in nci_rx_work() (git-fixes).
- commit b2f9141
- net, sunrpc: Remap EPERM in case of connection failure in
xs_tcp_setup_socket (CVE-2024-42246 bsc#1228989).
- Refresh
patches.suse/SUNRPC-improve-swap-handling-scheduling-and-PF_MEMAL.patch.
- commit 135ee65
- powerpc/topology: Check if a core is online (bsc#1214285
bsc#1205462 ltc#200161 ltc#200588 git-fixes).
- cpu/SMT: Enable SMT only if a core is online (bsc#1214285
bsc#1205462 ltc#200161 ltc#200588 git-fixes).
- commit bf2704c
- ata: libata-core: Fix null pointer dereference on error (CVE-2024-41098 bsc#1228467).
- commit 706447c
- vsock: correct removal of socket from the list (bsc#1227996).
- commit fa0bbe3
- x86/xen: Drop USERGS_SYSRET64 paravirt call (CVE-2021-4440
bsc#1227069).
- Refresh
patches.suse/x86-entry_64-Add-VERW-just-before-userspace-transition.patch.
- Refresh
patches.suse/x86-xen-add-xenpv_restore_regs_and_return_to_usermode.patch.
- commit 8c4b30e
- tcp_metrics: validate source addr length
(CVE-2024-42154 bsc#1228507).
- commit 21723ca
- memcg: protect concurrent access to mem_cgroup_idr (git-fixes).
- commit 7946225
- x86/pv: Switch SWAPGS to ALTERNATIVE (CVE-2021-4440
bsc#1227069).
- Refresh patches.suse/x86-Add-magic-AMD-return-thunk.patch.
- Refresh
patches.suse/x86-entry-add-kernel-ibrs-implementation.patch.
- commit 0ebe004
- vsock: remove vsock from connected table when connect is
interrupted by a signal (CVE-2022-48786 bsc#1227996).
- commit 1f3fc69
- libceph: fix race between delayed_work() and ceph_monc_stop()
(bsc#1228959 CVE-2024-42232).
- commit 498ef72
- nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
(git-fixes CVE-2024-35915 bsc#1224479).
- commit e2eb32a
- rpm/kernel-binary.spec.in: fix klp_symbols macro
The commit below removed openSUSE filter from %ifs of the klp_symbols
definition. But it removed -c of grep too and that causes:
error: syntax error in expression: 01 && ( || 1 )
error: ^
error: unmatched (: 01 && ( || 1 )
error: ^
error: kernel-default.spec:137: bad %if condition: 01 && ( || 1 )
So reintroduce -c to the PTF's grep.
Fixes: fd0b293bebaf (kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042).)
- commit 4a36fe3
- rpm/kernel-binary.spec.in: Fix build regression
The previous fix forgot to take over grep -c option that broke the
conditional expression
- commit d29edf2
- kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042).
After the Jump project the kernel used by SLE and openSUSE Leap are the
same. As consequence the klp_symbols variable is set, enabling
kernel-default-livepatch-devel on both SLE and openSUSE.
The current rules to avoid enabling the package exclude openSUSE
Tumbleweed alone, which doesn't makes sense for now. Enabling
kernel-default-livepatch-devel on TW makes it easier to test the
creation of kernel livepatches of the next SLE versions.
- commit fd0b293
- Update
patches.suse/0001-ocfs2-fix-DIO-failure-due-to-insufficient-transactio.patch
(bsc#1216834 CVE-2024-42077 bsc#1228516).
- Update
patches.suse/ocfs2-strict-bound-check-before-memcmp-in-ocfs2_xatt.patch
(bsc#1228410 CVE-2024-41016).
- Update
patches.suse/usb-atm-cxacru-fix-endpoint-checking-in-cxacru_bind.patch
(git-fixes CVE-2024-41097 bsc#1228513).
- Update
patches.suse/x86-bhi-Avoid-warning-in-DB-handler-due-to-BHI-mitigation.patch
(git-fixes CVE-2024-42240 bsc#1228966).
Add CVE references.
- commit 97c33e4
- net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx()
from __netif_rx() (CVE-2024-42110 bsc#1228501).
- bnx2x: Fix multiple UBSAN array-index-out-of-bounds
(CVE-2024-42148 bsc#1228487).
- commit 8188617
- inet_diag: Initialize pad field in struct inet_diag_req_v2
(CVE-2024-42106 bsc#1228493).
- commit 71e61fd
- tipc: fix kernel panic when enabling bearer (CVE-2022-48865
bsc#1228065).
- commit a0e7a51
- s390/sclp: Fix sclp_init() cleanup on failure (CVE-2024-41068
bsc#1228579).
- commit 1a2e580
- btrfs: fix processing of delayed tree block refs during backref
walking (bsc#1228982).
- btrfs: Remove unused op_key var from add_delayed_refs
(bsc#1228982).
- commit 1382fa0
- tpm: tpm1_bios_measurements_next should increase position index
(bsc#1082555).
- tpm: access command header through struct in tpm_try_transmit()
(bsc#1082555).
- commit f79c4b3
- tpm: Prevent hwrng from activating during resume (bsc#1082555).
- tpm: Allow system suspend to continue when TPM suspend fails
(bsc#1082555).
- tpm: Add a flag to indicate TPM power is managed by firmware
(bsc#1082555).
- commit 7eb0e28
- kernel-binary: generate and install compile_commands.json (bsc#1228971)
This file contains the command line options used to compile every C file.
It's useful for the livepatching team.
- commit 8efe375
- tpm/tpm_crb: Fix error message in __crb_relinquish_locality()
(bsc#1082555).
- commit a397ffb
- tpm: Revert "tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing
for interrupts" (bsc#1082555).
- commit b8cd04a
- xdp: Remove WARN() from __xdp_reg_mem_model() (bsc#1228482
CVE-2024-42082).
- commit 3f265d8
- pinctrl: fix deadlock in create_pinctrl() when handling
- EPROBE_DEFER (CVE-2024-42090 bsc#1228449).
- commit f210b8f
- packaging: Add case-sensitive perl option parsing
A recent change in Getopt::Long [1]:
Changes in version 2.55
- ----------------------
* Fix long standing bug that duplicate options were not detected
when the options differ in case while ignore_case is in effect.
This will now yield a warning and become a fatal error in a future
release.
perl defaults to ignore_case by default, switch it off to avoid
accidental misparsing of options.
This was suggested after similar change in scripts/.
- commit e978477
- drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes (CVE-2024-42101 bsc#1228495).
- commit f00bb1f
- drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc (CVE-2024-42228 bsc#1228667).
- commit d4e3f63
- btrfs: send: fix send failure of a subcase of orphan inodes
(bsc#1228030).
- btrfs: send: fix failures when processing inodes with no links
(bsc#1228030).
- commit 9fd4ec5
- btrfs: send: use boolean types for current inode status
(bsc#1228030).
- commit 2ab676b
- btrfs: send: refactor arguments of get_inode_info()
(bsc#1228030).
- commit 3731717
- kABI: Hide the new last_cc member in a hole in struct tpm_chip
(bsc#1082555).
- commit fac3e7a
- btrfs: send: always use the rbtree based inode ref management
infrastructure (bsc#1228030).
- commit 252130e
- btrfs: fix 64bit compat send ioctl arguments not initializing
version member (bsc#1228030).
- btrfs: fix send ioctl on 32bit with 64bit kernel (bsc#1228030).
- btrfs: send: add new command FILEATTR for file attributes
(bsc#1228030).
- btrfs: send: add stream v2 definitions (bsc#1228030).
- btrfs: send: avoid copying file data (bsc#1228030).
- btrfs: send: explicitly number commands and attributes
(bsc#1228030).
- btrfs: send: get rid of i_size logic in send_write()
(bsc#1228030).
- btrfs: send: prepare for v2 protocol (bsc#1228030).
- btrfs: send: remove unused send_ctx::{total,cmd}_send_size
(bsc#1228030).
- Refresh
patches.suse/Btrfs-fix-race-between-send-and-deduplication-that-l.patch.
- Refresh
patches.suse/btrfs-send-ensure-send_fd-is-writable.patch.
- Refresh
patches.suse/btrfs-send-fix-sending-link-commands-for-existing-fi.patch.
- commit 956ca27
- x86/bhi: Avoid warning in #DB handler due to BHI mitigation (git-fixes).
- commit f899605
- Refresh patches.suse/IB-hfi1-Fix-bugs-with-non-PAGE_SIZE-end-multi-iovec-.patch
Alt-commit added
Blacklist the follow-up fix of the Alt-commit
- commit c3542b0
- ima: Fix use-after-free on a dentry's dname.name (bsc#1227716
CVE-2024-39494).
- commit 2e3d558
- x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI (git-fixes).
- Update config files.
- commit 4549b89
- x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto (git-fixes).
This commit was missing for SLE12-SP5 which made the performance profile
of SLE12-SP5 and SLE15-SP[56] differ. Our decision was to follow
upstream w.r.t how BHI is going to be mitigated and the decision was to
do away with 'auto' mode.
- Update config files.
- commit 02bfc90
- Sort BHI mitigation patches
- Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch.
- Refresh
patches.suse/x86-bhi-Add-support-for-clearing-branch-history-at-syscall.patch.
- Refresh patches.suse/x86-bhi-Define-SPEC_CTRL_BHI_DIS_S.patch.
- Refresh
patches.suse/x86-bhi-Enumerate-Branch-History-Injection-BHI-bug.patch.
- Refresh patches.suse/x86-bhi-Mitigate-KVM-by-default.patch.
- Refresh
patches.suse/x86-cpufeature-Add-missing-leaf-enumeration.patch.
- commit f2f0729
- PCI: hv: Return zero, not garbage, when reading
PCI_INTERRUPT_PIN (git-fixes).
- commit 08ef890
- kABI: do not rename tpm_do_selftest, tpm_pcr_read_dev, and tpm1_getcap
(bsc#1082555).
- Delete patches.kabi/kABI-Do-not-rename-tpm_getcap.patch
- commit 5a6f1d9
- kABI: Do not rename tpm_getcap (bsc#1082555).
- commit 01263dd
- kABI: re-export tpm2_calc_ordinal_duration (bsc#1082555).
- commit 1303a23
- kABI: Instead of changing the pcr argument type add a local
variable of the desired type, and assign it from the actual
argument (bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- commit e919992
- kABI: no need to store the tpm long long duration in tpm_chip
struct, it is an arbitrary hardcoded value (bsc#1082555).
- commit 75cc28e
- kABI: do not change return type of tpm_tis_update_timeouts
(bsc#1082555).
- commit 57d9ed9
- Move kABI patch to kABI section.
- commit 3f941d1
- KVM: PPC: Book3S HV: remove extraneous asterisk from
rm_host_ipi_action() comment (bsc#1065729).
- KVM: PPC: Book3S HV: Don't take kvm->lock around
kvm_for_each_vcpu (bsc#1065729).
- KVM: PPC: Book3S: Use new mutex to synchronize access to rtas
token list (bsc#1065729).
- Refresh patches.suse/KVM-PPC-Book3S-Fix-H_RTAS-rets-buffer-overflow.patch
- KVM: PPC: Book3S: Only report KVM_CAP_SPAPR_TCE_VFIO on powernv
machines (bsc#1065729).
- KVM: PPC: Move and undef TRACE_INCLUDE_PATH/FILE (bsc#1065729).
- KVM: PPC: Inform the userspace about TCE update failures
(bsc#1065729).
- KVM: PPC: Book3S PR: Exiting split hack mode needs to fixup
both PC and LR (bsc#1065729).
- commit ad6fee4
- x86: stop playing stack games in profile_pc() (bsc#1228633
CVE-2024-42096).
- commit 0bc3d2d
- btrfs: send: remove stale code when checking for shared extents
(bsc#1228030).
- btrfs: silence maybe-uninitialized warning in clone_range
(bsc#1228030).
- commit 095e644
- Btrfs: incremental send, fix emission of invalid clone
operations (bsc#1228030).
- commit 88a98fe
- Btrfs: send, improve clone range (bsc#1228030).
- commit 8a72517
- btrfs: remove unused members dir_path from recorded_ref
(bsc#1228030).
- Refresh
patches.suse/btrfs-incremental-send-fix-invalid-path-for-unlink-commands.patch.
- Refresh
patches.suse/btrfs-send-fix-sending-link-commands-for-existing-fi.patch.
- commit 980e08a
- liquidio: Adjust a NULL pointer handling path in
lio_vf_rep_copy_packet (CVE-2024-39506 bsc#1227729).
- i40e: Fix queues reservation for XDP (CVE-2021-47619
bsc#1226645).
- commit 37ce537
- btrfs: send: remove unused found_type parameter to
lookup_dir_item_inode() (bsc#1228030).
- commit bc238fe
- scsi: qla2xxx: Convert comma to semicolon (bsc#1228850).
- scsi: qla2xxx: Update version to 10.02.09.300-k (bsc#1228850).
- scsi: qla2xxx: Use QP lock to search for bsg (bsc#1228850).
- scsi: qla2xxx: Reduce fabric scan duplicate code (bsc#1228850).
- scsi: qla2xxx: Fix optrom version displayed in FDMI
(bsc#1228850).
- scsi: qla2xxx: During vport delete send async logout explicitly
(bsc#1228850).
- scsi: qla2xxx: Complete command early within lock (bsc#1228850).
- scsi: qla2xxx: Fix flash read failure (bsc#1228850).
- scsi: qla2xxx: Return ENOBUFS if sg_cnt is more than one for
ELS cmds (bsc#1228850).
- scsi: qla2xxx: Fix for possible memory corruption (bsc#1228850).
- scsi: qla2xxx: validate nvme_local_port correctly (bsc#1228850).
- scsi: qla2xxx: Unable to act on RSCN for port online
(bsc#1228850).
- scsi: qla2xxx: Remove unused struct 'scsi_dif_tuple'
(bsc#1228850).
- scsi: qla2xxx: Fix debugfs output for fw_resource_count
(bsc#1228850).
- scsi: qla2xxx: Drop driver owner assignment (bsc#1228850).
- scsi: qla2xxx: Avoid possible run-time warning with long
model_num (bsc#1228850).
- string.h: Introduce memtostr() and memtostr_pad() (bsc#1228850).
- commit 2402124
- nvme: fixup comment for nvme RDMA Provider Type (git-fixes).
- commit 67b36fc
- check-for-config-changes: ignore also GCC_ASM_GOTO_OUTPUT_BROKEN
Mainline commit f2f6a8e88717 ("init/Kconfig: remove
CONFIG_GCC_ASM_GOTO_OUTPUT_WORKAROUND") replaced
GCC_ASM_GOTO_OUTPUT_WORKAROUND with GCC_ASM_GOTO_OUTPUT_BROKEN. Ignore both
when checking config changes.
- commit b60be3e
- IB/core: Implement a limit on UMAD receive List (bsc#1228743 CVE-2024-42145)
- commit 9aa0d29
- Update
patches.suse/Bluetooth-SCO-Fix-not-validating-setsockopt-user-inp.patch
(bsc#1224576 CVE-2024-35966 CVE-2024-35967 bsc#1224587).
- Update
patches.suse/RDMA-mlx5-Add-check-for-srq-max_sge-attribute.patch
(git-fixes CVE-2024-40990 bsc#1227824).
- Update
patches.suse/USB-class-cdc-wdm-Fix-CPU-lockup-caused-by-excessive.patch
(git-fixes CVE-2024-40904 bsc#1227772).
- Update
patches.suse/ocfs2-fix-races-between-hole-punching-and-AIO-DIO.patch
(bsc#1227849 CVE-2024-40943).
- Update
patches.suse/tracing-trigger-Fix-to-return-error-if-failed-to-alloc-snapshot.patch
(git-fixes CVE-2024-26920 bsc#1228237).
- commit 71c68bc
- Update
patches.suse/SUNRPC-Fix-UAF-in-svc_tcp_listen_data_ready.patch
(git-fixes CVE-2023-52885 bsc#1227750).
- commit 4594a5d
- Update
patches.suse/Input-aiptek-properly-check-endpoint-type.patch
(git-fixes CVE-2022-48836 bsc#1227989).
- Update
patches.suse/net-ieee802154-at86rf230-Stop-leaking-skb-s.patch
(git-fixes CVE-2022-48794 bsc#1228025).
- Update
patches.suse/net-packet-fix-slab-out-of-bounds-access-in-packet_r.patch
(CVE-2022-20368 bsc#1202346 CVE-2022-48839 bsc#1227985).
- Update
patches.suse/net-usb-ax88179_178a-Fix-out-of-bounds-accesses-in-R.patch
(bsc#1196018 CVE-2022-28748 CVE-2022-2964 CVE-2022-48805
bsc#1227969).
- commit 55fdbd1
- scsi: qedf: Make qedf_execute_tmf() non-preemptible (CVE-2024-42124 bsc#1228705)
- commit 7bd7589
- media: dvb-frontends: tda10048: Fix integer overflow (CVE-2024-42223 bsc#1228726)
- commit 4d685fd
- drm/amd/display: Skip finding free audio for unknown engine_id (CVE-2024-42119 bsc#1228584)
- commit f0a5549
- drm/amd/display: Check pipe offset before setting vblank (CVE-2024-42120 bsc#1228588)
- commit d85398e
- drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes (CVE-2024-41095 bsc#1228662)
- commit bb0cd8f
- btrfs: send: fix sending link commands for existing file paths
(bsc#1228030).
- commit 5a1f564
- net: dsa: mv88e6xxx: Correct check for empty list (CVE-2024-42224 bsc#1228723)
- commit f7ea584
- wifi: cfg80211: wext: add extra SIOCSIWSCAN data check (CVE-2024-41072 bsc#1228626)
- commit c131ba5
- bpf, sockmap: Fix partial copy_page_to_iter so progress can still be made (CVE-2024-41048 bsc#1228565)
- commit 79dff63
- skmsg: Skip zero length skb in sk_msg_recvmsg (CVE-2024-41048 bsc#1228565)
Based on c9c89dcd872e ("bpf, sockmap: Fix partial copy_page_to_iter so
progress can still be made"), previous commit.
Upstream commit 2bc793e3272a13 ("skmsg: Extract __tcp_bpf_recvmsg() and
tcp_bpf_wait_data()") moved the code from net/ipv4/tcp_bpf.c to
net/core/skmsg.c.
- commit 80be5ae
- net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
(CVE-2024-40995 bsc#1227830).
- commit ee1ce8a
- btrfs: send: introduce recorded_ref_alloc and recorded_ref_free
(bsc#1228030).
- commit 2f5e245
- cgroup/cpuset: Prevent UAF in proc_cpuset_show() (bsc#1228801).
- commit e47e175
- ppp: reject claimed-as-LCP but actually malformed packets
(CVE-2024-41044 bsc#1228530).
- ibmvnic: Add tx check to prevent skb leak (CVE-2024-41066
bsc#1228640).
- commit 0bdb098
- net/dpaa2: Avoid explicit cpumask var allocation on stack
(CVE-2024-42093 bsc#1228680).
- dpaa2-eth: Refactor xps code (CVE-2024-42093 bsc#1228680).
- commit caf72f9
- drm/nouveau/dispnv04: fix null pointer dereference in (bsc#1228658 CVE-2024-41089)
- commit aec5d0e
- drm/radeon: check bo_va->bo is non-NULL before using it (bsc#1228567 CVE-2024-41060)
- commit 7a28cea
- NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
(CVE-2022-48829 bsc#1228055).
- NFSD: Fix ia_size underflow (CVE-2022-48828 bsc#1228054).
- NFSD: Fix the behavior of READ near OFFSET_MAX (CVE-2022-48827
bsc#1228037).
- commit 1c127f3
- btrfs: qgroup: fix quota root leak after quota disable failure
(bsc#1228655 CVE-2024-41078).
- commit 263e74a
- wifi: mac80211: Avoid address calculations via out of bounds
array indexing (CVE-2024-41071 bsc#1228625).
- commit be2129f
- powerpc/eeh: avoid possible crash when edev->pdev changes
(CVE-2024-41064 bsc#1228599).
- commit 145d8ea
- btrfs: make sure that WRITTEN is set on all metadata blocks (CVE-2024-35949 bsc#1224700)
Changes: adjust returned error codes to -EUCLEAN and drop definition of
the enum error.
- commit 6dc890d
- ila: block BH in ila_output() (CVE-2024-41081 bsc#1228617)
- commit 9ec349b
- scsi: qedi: Fix crash while reading debugfs attribute
(bsc#1227929 CVE-2024-40978).
- scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task
(bsc#1228013 CVE-2022-48792).
- scsi: qedf: Fix refcount issue when LOGO is received during TMF
(bsc#1228045 CVE-2022-48823).
- commit 2a5c419
- ext4: fix uninitialized ratelimit_state->lock access in
__ext4_fill_super() (bsc#1227866 CVE-2024-40998).
- commit 5fe487a
- hfsplus: fix uninit-value in copy_name (bsc#1228561
CVE-2024-41059).
- commit 8d75c30
- usb: musb: da8xx: fix a resource leak in probe() (git-fixes).
- commit bc4c361
- usb: atm: cxacru: fix endpoint checking in cxacru_bind()
(git-fixes).
- commit c9a5140
- USB: class: cdc-wdm: Fix CPU lockup caused by excessive log
messages (git-fixes).
- commit 7c21caa
- drm/amdgpu: fix UBSAN warning in kv_dpm.c (bsc#1228235 CVE-2024-40987)
- commit 60606a5
- drm/vc4: Fix deadlock on DSI device attach error (bsc#1227975 CVE-2022-48826)
- commit bcda77c
- drm/vc4: dsi: Only register our component once a DSI device is (bsc#1227975)
- commit 0a73252
- genirq: Add IRQF_NO_AUTOEN for request_irq/nmi() (bsc#1222625
CVE-2024-27437).
- commit 351bbe3
- ocfs2: add bounds checking to ocfs2_check_dir_entry()
(bsc#1228409 CVE-2024-41015).
- ocfs2: strict bound check before memcmp in
ocfs2_xattr_find_entry() (bsc#1228410).
- ocfs2: add bounds checking to ocfs2_xattr_find_entry()
(bsc#1228410 CVE-2024-41016).
- ocfs2: remove redundant assignment to variable free_space
(bsc#1228409).
- commit 2a658bc
- vfio/pci: Disable auto-enable of exclusive INTx IRQ (bsc#1222625
CVE-2024-27437).
- commit 9829ce8
- Fix reference in patches.suse/ixgbe-Fix-NULL-pointer-dereference-in-ixgbe_xdp_setu.patch (CVE-2021-47399 bsc#1225328)
- commit 7933225
- ocfs2: fix DIO failure due to insufficient transaction credits
(bsc#1216834).
- commit e4fdc60
- Bluetooth: hci_core: cancel all works upon hci_unregister_dev() (CVE-2024-41063 bsc#1228580)
- commit 95070bc
- netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers (CVE-2024-42070 bsc#1228470)
- commit d9e81e6
- KVM: PPC: Book3S: Fix some RCU-list locks (git-fixes).
- commit e20a5cb
- KVM: PPC: Book3S HV: Prevent UAF in
kvm_spapr_tce_attach_iommu_group() (bsc#1228581 CVE-2024-41070).
- commit 1cd5894
- tpm: use tpm_msleep() value as max delay (bsc#1082555).
- Refresh patches.suse/tpm-use-struct-tpm_chip-for-tpm_chip_find_get.patch
- commit fd76767
- tpm_tis: Resend command to recover from data transfer errors
(bsc#1082555).
- tpm_tis: Explicitly check for error code (bsc#1082555).
- tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation
(bsc#1082555).
- tpm, tpm_tis: correct tpm_tis_flags enumeration values
(bsc#1082555).
- tpm_tis: Use tpm_chip_{start,stop} decoration inside
tpm_tis_resume (bsc#1082555).
- tpm, tpm_tis: Claim locality when interrupts are reenabled on
resume (bsc#1082555).
- tpm, tpm: Implement usage counter for locality (bsc#1082555).
- tpm, tpm_tis: Only handle supported interrupts (bsc#1082555).
- tpm, tpm_tis: Claim locality before writing interrupt registers
(bsc#1082555).
- tpm, tpm_tis: Do not skip reset of original interrupt vector
(bsc#1082555).
- tpm, tpm_tis: Disable interrupts if tpm_tis_probe_irq() failed
(bsc#1082555).
- tpm, tpm_tis: Claim locality before writing TPM_INT_ENABLE
register (bsc#1082555).
- tpm, tpm_tis: Avoid cache incoherency in test for interrupts
(bsc#1082555).
- tpm: tpm_tis: Add the missed acpi_put_table() to fix memory leak
(bsc#1082555).
- tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak
(bsc#1082555).
- char: tpm: Protect tpm_pm_suspend with locks (bsc#1082555).
- tpm: Fix buffer access in tpm2_get_tpm_pt() (bsc#1082555).
- tpm: Fix error handling in async work (bsc#1082555).
- tpm: fix NPE on probe for missing device (bsc#1082555).
- tpm_tis: Fix an error handling path in 'tpm_tis_core_init()'
(bsc#1082555).
- tpm: fix Atmel TPM crash caused by too frequent queries
(bsc#1082555).
- tpm: Replace WARN_ONCE() with dev_err_once() in tpm_tis_status()
(bsc#1082555).
- tpm, tpm_tis: Reserve locality in tpm_tis_resume()
(bsc#1082555).
- tpm, tpm_tis: Extend locality handling to TPM2 in
tpm_tis_gen_interrupt() (bsc#1082555).
- tpm: vtpm_proxy: Avoid reading host log when using a virtual
device (bsc#1082555).
- tpm, tpm_tis: Decorate tpm_tis_gen_interrupt() with
request_locality() (bsc#1082555).
- tpm, tpm_tis: Decorate tpm_get_timeouts() with
request_locality() (bsc#1082555).
- tpm: Remove tpm_dev_wq_lock (bsc#1082555).
- tpm_tis: Add a check for invalid status (bsc#1082555).
- kABI: tpm2-space: Do not add buf_size to struct tpm_space
(bsc#1082555).
- tpm: Unify the mismatching TPM space buffer sizes (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: Fix TIS locality timeout problems (bsc#1082555).
- tpm: Handle negative priv->response_len in tpm_common_read()
(bsc#1082555).
- tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's"
(bsc#1082555).
- tpm: Revert "tpm_tis: reserve chip for duration of
tpm_tis_core_init" (bsc#1082555).
- Refresh patches.suse/tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch
- tpm: fix invalid locking in NONBLOCKING mode (bsc#1082555).
- tpm_tis: reserve chip for duration of tpm_tis_core_init
(bsc#1082555).
- Refresh patches.suse/tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch
- tpm: Wrap the buffer from the caller to tpm_buf in tpm_send()
(bsc#1082555).
- tpm_tis_core: Turn on the TPM before probing IRQ's
(bsc#1082555).
- Refresh patches.suse/tpm_tis_core-Set-TPM_CHIP_FLAG_IRQ-before-probing-fo.patch
- tpm: Fix null pointer dereference on chip register error path
(bsc#1082555).
- tpm: Actually fail on TPM errors during "get random"
(bsc#1082555).
- tpm: fix an invalid condition in tpm_common_poll (bsc#1082555).
- tpm: turn on TPM on suspend for TPM 1.x (bsc#1082555).
- tpm: remove @flags from tpm_transmit() (bsc#1082555).
- Refresh patches.suse/tpm-Fix-TPM-1.2-Shutdown-sequence-to-prevent-future-.patch
- Refresh patches.suse/tpm-add-request_locality-before-write-TPM_INT_ENABLE.patch
- Refresh patches.suse/tpm-fix-potential-NULL-pointer-access-in-tpm_del_cha.patch
- Refresh patches.kabi/kABI-Instead-of-changing-the-pcr-argument-type-add-a.patch
- tpm: take TPM chip power gating out of tpm_transmit()
(bsc#1082555).
- Refresh patches.suse/tpm-Fix-TPM-1.2-Shutdown-sequence-to-prevent-future-.patch
- Refresh patches.suse/tpm-add-request_locality-before-write-TPM_INT_ENABLE.patch
- Refresh patches.suse/tpm-fix-potential-NULL-pointer-access-in-tpm_del_cha.patch
- tpm: introduce tpm_chip_start() and tpm_chip_stop()
(bsc#1082555).
- tpm: remove TPM_TRANSMIT_UNLOCKED flag (bsc#1082555).
- tpm: use tpm_try_get_ops() in tpm-sysfs.c (bsc#1082555).
- tpm: remove @space from tpm_transmit() (bsc#1082555).
- tpm: move TPM space code out of tpm_transmit() (bsc#1082555).
- tpm: move tpm_validate_commmand() to tpm2-space.c (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: clean up tpm_try_transmit() error handling flow
(bsc#1082555).
- tpm: encapsulate tpm_dev_transmit() (bsc#1082555).
- tpm: declare struct tpm_header (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: print tpm2_commit_space() error inside tpm2_commit_space()
(bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: return 0 from pcrs_show() when tpm1_pcr_read() fails
(bsc#1082555).
- tpm: fix invalid return value in pubek_show() (bsc#1082555).
- tpm: use tpm_buf in tpm_transmit_cmd() as the IO parameter
(bsc#1082555).
- tpm: don't return bool from update_timeouts (bsc#1082555).
- tpm: add support for partial reads (bsc#1082555).
- tpm: use u32 instead of int for PCR index (bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- tpm1: reimplement tpm1_continue_selftest() using tpm_buf
(bsc#1082555).
- tpm1: reimplement SAVESTATE using tpm_buf (bsc#1082555).
- tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read() (bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- tpm1: implement tpm1_pcr_read_dev() using tpm_buf structure
(bsc#1082555).
- tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure
(bsc#1082555).
- tpm: add tpm_auto_startup() into tpm-interface.c (bsc#1082555).
- tpm: factor out tpm_startup function (bsc#1082555).
- tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
(bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- tpm: move tpm 1.x selftest code from tpm-interface.c tpm1-cmd.c
(bsc#1082555).
- Refresh patches.kabi/kABI-Do-not-rename-tpm_getcap.patch
- tpm: factor out tpm1_get_random into tpm1-cmd.c (bsc#1082555).
- Refresh patches.kabi/kABI-Do-not-rename-tpm_getcap.patch
- tpm: move tpm_getcap to tpm1-cmd.c (bsc#1082555).
- tpm: move tpm1_pcr_extend to tpm1-cmd.c (bsc#1082555).
- tpm: factor out tpm_get_timeouts() (bsc#1082555).
- Refresh patches.kabi/kABI-no-need-to-store-the-tpm-long-long-duration-in-.patch
- tpm: add tpm_calc_ordinal_duration() wrapper (bsc#1082555).
- tpm: factor out tpm 1.x duration calculation to tpm1-cmd.c
(bsc#1082555).
- tpm: add support for nonblocking operation (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: add ptr to the tpm_space struct to file_priv (bsc#1082555).
- tpm: replace TPM_TRANSMIT_RAW with TPM_TRANSMIT_NESTED
(bsc#1082555).
- tpm: rename tpm_chip_find_get() to tpm_find_get_ops()
(bsc#1082555).
- tpm: migrate tpm2_get_random() to use struct tpm_buf
(bsc#1082555).
- Refresh patches.suse/tpm-fix-response-size-validation-in-tpm_get_random.patch
- tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf
(bsc#1082555).
- tpm: migrate tpm2_probe() to use struct tpm_buf (bsc#1082555).
- tpm: migrate tpm2_shutdown() to use struct tpm_buf
(bsc#1082555).
- tpm2: add longer timeouts for creation commands (bsc#1082555).
- tpm: fix buffer type in tpm_transmit_cmd (bsc#1082555).
- tpm: migrate pubek_show to struct tpm_buf (bsc#1082555).
- tpm: vtpm_proxy: Prevent userspace from sending driver command
(bsc#1082555).
- tpm, tpmrm: Mark tpmrm_write as static (bsc#1082555).
- tpm: remove struct tpm_pcrextend_in (bsc#1082555).
- Refresh patches.suse/tpm-consolidate-the-TPM-startup-code.patch
- tpm: fix byte order related arithmetic inconsistency in
tpm_getcap() (bsc#1082555).
- Refresh patches.suse/tpm-consolidate-the-TPM-startup-code.patch
- tpm: move TPM 1.2 code of tpm_pcr_extend() to tpm1_pcr_extend()
(bsc#1082555).
- Refresh patches.suse/tpm-use-struct-tpm_chip-for-tpm_chip_find_get.patch
- commit 989dcf1
- rpm/guards: fix precedence issue with control flow operator
With perl 5.40 it report the following error on rpm/guards script:
Possible precedence issue with control flow operator (exit) at scripts/guards line 208.
Fix the issue by adding parenthesis around ternary operator.
- commit 07b8b4e
- HID: usbhid: free raw_report buffers in usbhid_stop (bsc#1225238
CVE-2021-47405).
- commit 67ff2bd
- drm/radeon: fix UBSAN warning in kv_dpm.c (bsc#1227957 CVE-2024-40988)
- commit 4f641c6
- drm/exynos/vidi: fix memory leak in .get_modes() (bsc#1227828 CVE-2024-40932)
- commit d694b72
- ipack: ipoctal: fix module reference leak (bsc#1225241
CVE-2021-47403).
- commit 3f2bac7
- mac80211: fix use-after-free in CCMP/GCMP RX (bsc#1225214
CVE-2021-47388).
- commit 180ca41
- xfs: refactor xfs_verifier_error and xfs_buf_ioerror
(git-fixes).
- Refresh
patches.suse/xfs-don-t-ever-return-a-stale-pointer-from-__xfs_dir.patch.
- commit ac4dc1f
- xfs: remove XFS_WANT_CORRUPTED_RETURN from dir3 data verifiers
(git-fixes).
- commit 5d31a73
- xfs: check that dir block entries don't off the end of the
buffer (git-fixes).
- commit 46f96de
- xfs: add bounds checking to xlog_recover_process_data
(bsc#1228408 CVE-2024-41014).
- commit b3db770
- tun: add missing verification for short frame (CVE-2024-41091
bsc#1228327).
- tap: add missing verification for short frame (CVE-2024-41090
bsc#1228328).
- net: ena: Add validation for completion descriptors consistency
(CVE-2024-40999 bsc#1227913).
- net: mvpp2: clear BM pool before initialization (CVE-2024-35837
bsc#1224500).
- commit 69b68ee
- Update
patches.suse/xhci-Fix-incorrect-tracking-of-free-space-on-transfe.patch.
Fix a backporting mistake which was causing the following warning:
drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
drivers/usb/host/xhci-ring.c:3255:6: warning: unused variable 'trbs_freed' [-Wunused-variable]
- commit 787d888
- xhci: Poll for U0 after disabling USB2 LPM (git-fixes).
- commit c66374c
- sit: do not call ipip6_dev_free() from sit_init_net()
(CVE-2021-47588 bsc#1226568).
- commit 9afcbd9
- ipv6: sr: fix incorrect unregister order (git-fixes).
- commit 9f9395f
- Refresh
patches.suse/powerpc-rtas-Prevent-Spectre-v1-gadget-construction-.patch.
- commit af33133
- vt_ioctl: fix array_index_nospec in vt_setactivate
(CVE-2022-48804 bsc#1227968).
- commit ee44df4
- serial: imx: Introduce timeout when waiting on transmitter empty
(CVE-2024-40967 bsc#1227891).
- commit 9b7db88
- kABI: tty: add the option to have a tty reject a new ldisc
(kabi CVE-2024-40966 bsc#1227886).
- tty: add the option to have a tty reject a new ldisc
(CVE-2024-40966 bsc#1227886).
- commit 16b4088
- net-sysfs: add check for netdevice being present to speed_show (CVE-2022-48850 bsc#1228071)
- commit 9fdf37b
- Update
patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_report_tgtpgs.patch
(bsc#1222824 CVE-2021-47219).
Fix incorrect Bug number and incorrect CVE number.
- commit b4dbf5c
- Update
patches.suse/scsi-lpfc-Release-hbalock-before-calling-lpfc_worker_wake_up.patch
(bsc#1225820 CVE-2024-36924).
Fix incorrect CVE number.
- commit cb94423
- Update
patches.suse/nvme-rdma-remove-redundant-reference-between-ib_devi.patch
(bsc#1149446).
Fix bug reference (missing digit).
- commit 4f5320f
- Update patches.suse/ovl-fix-failure-to-fsync-lower-dir.patch
(bsc#1088701).
Fix bug reference (missing digit).
- commit 718aec5
- usb: core: Don't hold the device lock while sleeping in
do_proc_control() (CVE-2021-47582 bsc#1226559).
- commit ff00ceb
- USB: usbfs: fix mmap dma mismatch (CVE-2021-47582 bsc#1226559).
- commit 6c5305a
- usb: add a hcd_uses_dma helper (git-fixes).
- commit f8aa53d
- ssb: Fix potential NULL pointer dereference in
ssb_device_uevent() (CVE-2024-40982 bsc#1227865).
- commit 9fbb468
- isdn: mISDN: Fix sleeping function called from invalid context
(bsc#1225346 CVE-2021-47468).
- commit 34167c4
- mac80211: limit injected vht mcs/nss in
ieee80211_parse_tx_radiotap (bsc#1225326 CVE-2021-47395).
- commit 2fdeaab
- tools lib: Fix builds when glibc contains strlcpy() (git-fixes).
- blacklist.conf: unblaclist it
This commit allows for local builds with newer glibc.
- commit 480e775
- PCI: Fix resource double counting on remove & rescan
(git-fixes).
- commit 68ca613
- ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table()
on failure path (CVE-2022-48810 bsc#1227936).
- commit 7af1a4f
- wifi: ath9k: Fix potential array-index-out-of-bounds read in
ath9k_htc_txstatus() (CVE-2023-52594 bsc#1221045).
- commit d04a718
- sctp: fix kernel-infoleak for SCTP sockets (CVE-2022-48855
bsc#1228003).
- commit 5317e78
- scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()
(bsc#1226550 CVE-2021-47580).
- commit 72ff240
- ipv6: sr: fix possible use-after-free and null-ptr-deref
(bsc#1222372 CVE-2024-26735).
- commit 5258c5a
- signal: Introduce clear_siginfo (git-fixes).
- commit 276fe89
- Update
patches.suse/scsi-scsi_debug-Fix-type-in-min_t-to-avoid-stack-OOB.patch
(bsc#1226550 CVE-2021-47580).
Fix incorrect bug#
- commit a8e747b
- scsi: bfa: Ensure the copied buf is NUL terminated (bsc#1226786
CVE-2024-38560).
- commit 2623515
- ibmvnic: don't release napi in __ibmvnic_open() (bsc#1227928
CVE-2022-48811).
- commit b1dc7a1
- Update References
patches.suse/Bluetooth-SMP-Fail-if-remote-and-local-public-keys-a.patch
(bsc#1186463, CVE-2021-0129, CVE-2020-26558, bsc#1179610,
CVE-2020-26558).
- commit ef3041a
- gve: Clear napi->skb before dev_kfree_skb_any() (CVE-2024-40937
bsc#1227836).
- net: hns3: fix kernel crash problem in concurrent scenario
(CVE-2024-39507 bsc#1227730).
- ibmvnic: don't release napi in __ibmvnic_open() (CVE-2022-48811
bsc#1227928).
- commit 753a87a
- Refresh
patches.suse/ipv6-sr-fix-missing-sk_buff-release-in-seg6_input_co.patch.
Fix broken patch, which only applys with rapidquilt but not with normal
patch.
- commit 9ba3403
- vmxnet3: disable rx data ring on dma allocation failure
(CVE-2024-40923 bsc#1227786).
- commit 4f3a9e9
- wifi: iwlwifi: mvm: don't read past the mfuart notifcation
(git-fixes CVE-2024-40941 bsc#1227771).
- commit e4b5384
- ethernet: Fix error handling in xemaclite_of_probe (CVE-2022-48860 bsc#1228008)
- commit f50353a
- Bluetooth: RFCOMM: Fix not validating setsockopt user input
(bsc#1224576 CVE-2024-35966).
- commit 68cb9dc
- mISDN: Fix memory leak in dsp_pipeline_build() (CVE-2022-48863
bsc#1228063).
- commit 98e043d
- KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
(CVE-2024-40953, bsc#1227806).
- commit b18a093
- vmci: prevent speculation leaks by sanitizing event in event_deliver() (CVE-2024-39499 bsc#1227725)
- commit d42ba53
- HID: core: remove unnecessary WARN_ON() in implement() (CVE-2024-39509 bsc#1227733)
- commit fe2364e
- bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() (CVE-2024-39487 bsc#1227573)
- commit b775587
- Update
patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_readcap16.patch.
Fix a build warning about using min() vs min_t().
- commit a4b6164
- xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
(CVE-2024-40959 bsc#1227884).
- commit 38ba090
- ocfs2: fix races between hole punching and AIO+DIO (CVE-2024-40943 bsc#1227849).
- commit a8b4b50
- net/sched: act_skbmod: prevent kernel-infoleak (CVE-2024-35893 bsc#1224512)
- commit 3a867bb
- ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup (CVE-2021-47399 1225328)
- commit f559799
- mlxsw: thermal: Fix out-of-bounds memory accesses (CVE-2021-47441 bsc#1225224)
Simplified backport. Upstream patch removes code that does not exist in
SLE12-SP5, the only relevant fix is the bounds checking.
- commit 0b8797d
- cfg80211: call cfg80211_stop_ap when switch from P2P_GO type (CVE-2021-47194 bsc#1222829)
- commit 6cc8bdc
- netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() (CVE-2024-27020 bsc#1223815)
- commit cfe8cf0
- net: mana: Fix the extra HZ in mana_hwc_send_request (git-fixes).
- net: mana: select PAGE_POOL (git-fixes).
- hv_netvsc: rndis_filter needs to select NLS (git-fixes).
- Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj (git-fixes, bsc#1227924, CVE-2022-48775).
- Tools: hv: kvp: eliminate 'may be used uninitialized' warning (git-fixes).
- tools: hv: fix KVP and VSS daemons exit code (git-fixes).
- commit 51c2361
- netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() (CVE-2024-27019 bsc#1223813)
- commit 2fcd5af
- wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
(CVE-2024-40929 bsc#1227774).
- wifi: mac80211: Fix deadlock in
ieee80211_sta_ps_deliver_wakeup() (CVE-2024-40912 bsc#1227790).
- wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
(CVE-2024-40942 bsc#1227770).
- NFC: port100: fix use-after-free in port100_send_complete
(CVE-2022-48857 bsc#1228005).
- commit 1f497da
- ipv6: fib6_rules: avoid possible NULL dereference in
fib6_rule_action() (CVE-2024-36902 bsc#1225719).
- commit 4cdf9a2
- USB: core: Make do_proc_control() and do_proc_bulk() killable
(CVE-2021-47582 bsc#1226559).
- commit 6d322e2
- net: netlink: af_netlink: Prevent empty skb by adding a check
on len (CVE-2021-47606 bsc#1226555).
- commit 314dfef
- usb: get rid of pointless access_ok() calls (CVE-2021-47582
bsc#1226559).
- commit 6b48efc
- usb: usbfs: correct kernel->user page attribute mismatch
(CVE-2021-47582 bsc#1226559).
- commit d089a07
- USB: usbfs: Always unlink URBs in reverse order (CVE-2021-47582
bsc#1226559).
- commit 2364ecb
- usb: core: devio.c: Fix assignment of 0/1 to bool variables
(CVE-2021-47582 bsc#1226559).
- commit 202a764
- usb: usbfs: only account once for mmap()'ed usb memory usage
(CVE-2021-47582 bsc#1226559).
- commit a282a95
- USB: core: Fix compiler warnings in devio.c (CVE-2021-47582
bsc#1226559).
- commit d3c8045
- usb: core: Replace hardcoded check with inline function from
usb.h (CVE-2021-47582 bsc#1226559).
- commit a0c8b54
- usb: usbfs: use irqsave() in USB's complete callback
(CVE-2021-47582 bsc#1226559).
- commit 89f4a73
- signal: Replace memset(info,...) with clear_siginfo for clarity
(CVE-2021-47582 bsc#1226559).
- commit 10e5b53
- usbdevfs: get rid of field-by-field copyin (CVE-2021-47582
bsc#1226559).
- commit 9053160
- scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated
memory (bsc#1227762 CVE-2024-40901).
- scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
(bsc#1225820 CVE-2024-26924).
- scsi: scsi_debug: Fix type in min_t to avoid stack OOB
(bsc#1226560 CVE-2021-47580).
- commit 4de5c4e
- i40e: Fix VF MAC filter removal (CVE-2024-26830 bsc#1223012).
- commit 55935e5
- i40e: Do not allow untrusted VF to remove administratively
set MAC (CVE-2024-26830 bsc#1223012).
- nfp: Fix memory leak in nfp_cpp_area_cache_add() (CVE-2021-47516
bsc#1225427).
- i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc
(CVE-2021-47501 bsc#1225361).
- commit e2ee4f5
- net: ieee802154: fix null deref in parse dev addr (CVE-2021-47257 bsc#1224896).
- commit 41e01f4
- net/smc: Transitional solution for clcsock race issue (CVE-2022-48751 bsc#1226653). - Refresh patches.suse/net-smc-fix-fallback-failed-while-sendmsg-with-fasto.patch.
- commit 7ad7d3a
- drivers: core: synchronize really_probe() and dev_uevent()
(CVE-2024-39501 bsc#1227754).
- commit 1b7df5b
- ice: Do not use WQ_MEM_RECLAIM flag for workqueue (CVE-2023-52743 bsc#1225003)
- commit 0b6d94a
- net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings() (CVE-2021-47542 bsc#1225455)
- commit ce2e7bb
- ipv6: prevent NULL dereference in ip6_output() (CVE-2024-36901 bsc#1225711)
- commit ab46189
- i40e: Do not use WQ_MEM_RECLAIM flag for workqueue (CVE-2024-36004 bsc#1224545)
- commit de141a1
- nbd: null check for nla_nest_start (CVE-2024-27025 bsc#1223778)
- commit b887966
- btrfs: use latest_dev in btrfs_show_devname (CVE-2021-47599 bsc#1226571)
Simplified backport, keep mutex protection and only remove WARN_ON.
- commit 2ee6fb6
- net: prevent mss overflow in skb_segment() (CVE-2023-52435
bsc#1220138).
- commit 63a8256
- tipc: Check the bearer type before calling
tipc_udp_nl_bearer_add() (CVE-2024-26663 bsc#1222326).
- commit 91299f0
- inet_diag: fix kernel-infoleak for UDP sockets
(CVE-2021-47597 bsc#1226553).
- commit 5ef7515
- ipv6: sr: fix missing sk_buff release in seg6_input_core
(bsc#1227626 CVE-2024-39490).
- net: openvswitch: fix overwriting ct original tuple for ICMPv6
(bsc#1226783 CVE-2024-38558).
- net/smc: fix illegal rmb_desc access in SMC-D connection dump
(bsc#1220942 CVE-2024-26615).
- commit ee46311
- kabi/severities: Ignore tpm_transmit_cmd and tpm_tis_core_init
(bsc#1082555).
- commit c8a552a
- Bluetooth: SCO: Fix not validating setsockopt user input
(bsc#1224576 CVE-2024-35966).
- commit d80abbf
- Update
patches.suse/SUNRPC-Fix-loop-termination-condition-in-gss_free_in.patch
(git-fixes CVE-2024-36288 bsc#1226834).
- Update
patches.suse/arm64-asm-bug-Add-.align-2-to-the-end-of-__BUG_ENTRY.patch
(git-fixes CVE-2024-39488 bsc#1227618).
- Update
patches.suse/ax25-fix-use-after-free-bugs-caused-by-ax25_ds_del_t.patch
(CVE-2024-35887 bzg#1224663 bsc#1224663).
- Update
patches.suse/net-mlx5e-nullify-cq-dbg-pointer-in-mlx5_debug_cq_re.patch
(bsc#1225229 CVE-2021-47438 CVE-2021-47197 bsc#1222776).
- Update
patches.suse/nfs-Handle-error-of-rpc_proc_register-in-nfs_net_ini.patch
(git-fixes CVE-2024-36939 bsc#1225838).
- Update
patches.suse/scsi-lpfc-Move-NPIV-s-transport-unregistration-to-after-resource-clean-up.patch
(bsc#1225898 CVE-2024-36592 CVE-2024-36952).
- Update
patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_readcap16.patch
(bsc#122286 CVE-2021-47191 bsc#1222866).
- Update
patches.suse/soc-fsl-qbman-Always-disable-interrupts-when-taking-.patch
(bsc#1224683 CVE-2024-35819 CVE-2024-35806 bsc#1224699).
- commit 81c691f
- pstore/ram: Fix crash when setting number of cpus to an odd number (bsc#1221618, CVE-2023-52619).
- commit 03ca866
- Fix build warning
Refresh
patches.suse/PM-hibernate-x86-Use-crc32-instead-of-md5-for-hibernation-.patch.
- commit 33d6e41
- xhci: Fix incorrect tracking of free space on transfer rings
(CVE-2024-26659 bsc#1222317).
- commit 985549c
- xhci: process isoc TD properly when there was a transaction
error mid TD (CVE-2024-26659 bsc#1222317).
- commit 1966e44
- xhci: store TD status in the td struct instead of passing it
along (CVE-2024-26659 bsc#1222317).
- commit dba92cd
- xhci: Add a separate debug message for split transaction errors
(CVE-2024-26659 bsc#1222317).
- commit 93897b0
- usb: xhci: Remove ep_trb from finish_td() (CVE-2024-26659
bsc#1222317).
- commit 75b9c07
- usb: xhci: Remove ep_trb from xhci_cleanup_halted_endpoint()
(CVE-2024-26659 bsc#1222317).
- Refresh
patches.suse/xhci-remove-extra-loop-in-interrupt-context.patch.
- commit 93f2e51
- usb: xhci: remove unused variable ep_ring (CVE-2024-26659
bsc#1222317).
- commit 25ab80d
- xhci: remove extra loop in interrupt context (CVE-2024-26659
bsc#1222317).
- commit 58c6482
- Bluetooth: Fix memory leak in hci_req_sync_complete()
(bsc#1224571 CVE-2024-35978).
- commit 0071ef8
- xhci: get isochronous ring directly from endpoint structure
(CVE-2024-26659 bsc#1222317).
- commit 1c8c540
- crypto: s390/aes - Fix buffer overread in CTR mode
(CVE-2023-52669 bsc#1224637).
- commit bc65b53
- hwrng: core - Fix page fault dead lock on mmap-ed hwrng
(CVE-2023-52615 bsc#1221614).
- commit c3d2ac9
- ACPI: CPPC: Fix access width used for PCC registers (bsc#1224557
CVE-2024-35995).
- commit 33ff733
- ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro
(bsc#1224557 CVE-2024-35995).
- commit ae6202b
- SUNRPC: Fix a suspicious RCU usage warning (CVE-2023-52623
bsc#1222060).
- commit ffa9576
- ACPI: CPPC: Use access_width over bit_width for system memory
accesses (bsc#1224557 CVE-2024-35995).
- commit ef057c5
- ACPI: CPPC: Drop redundant local variable from cpc_read()
(bsc#1224557 CVE-2024-35995).
- commit 73812cd
- Update
patches.suse/scsi-bnx2fc-Remove-spin_lock_bh-while-releasing-resources-after-upload.patch
(bsc#1225767 CVE-2024-36919).
fix incorrect bug number
- commit d503d18
- crypto: scomp - fix req->dst buffer overflow (CVE-2023-52612
bsc#1221616).
- commit 3b5d943
- xhci: handle isoc Babble and Buffer Overrun events properly
(CVE-2024-26659 bsc#1222317).
- commit 98fde6e
- net_sched: fix a missing refcnt in tcindex_init() (bsc#1224975).
- commit 45da465
- net_sched: add a temporary refcnt for struct tcindex_data
(bsc#1224975).
- Refresh
patches.suse/net-sched-tcindex-update-imperfect-hash-filters-resp.patch.
- commit b3f881b
- net_sched: fix a memory leak in cls_tcindex (bsc#1224975).
- Refresh
patches.suse/net_sched-fix-an-OOB-access-in-cls_tcindex.patch.
- Refresh
patches.suse/net_sched-keep-alloc_hash-updated-after-hash-allocat.patch.
- commit 98c1fbb
- net: sched: fix memory leak in tcindex_partial_destroy_work (CVE-2021-47295 bsc#1224975)
- commit 280e278
- net_sched: hold rtnl lock in tcindex_partial_destroy_work() (bsc#1224975)
- commit 6f5da00
- blacklist.conf: convert entry to Alt-commit:
Refresh patches.suse/net_sched-fix-a-race-condition-in-tcindex_destroy.patch.
- commit 4a1ea17
- kernel-binary: vdso: Own module_dir
- commit ff69986
- Fix spurious WARNING caused by a qxl driver patch (bsc#1227213,bsc#1227191)
Refresh patches.suse/drm-qxl-fix-UAF-on-handle-creation.patch
- commit 55a7bf6
- ACPI: video: check for error while searching for backlight
device parent (bsc#1224686 CVE-2023-52693).
- commit aafdad5
- ACPI: LPIT: Avoid u32 multiplication overflow (bsc#1224627
CVE-2023-52683).
- commit 57dc5ae
- x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK (git-fixes).
- commit 90918cd
- netfilter: nft_set: preserve kabi (bsc#1215420 CVE-2023-4244).
- commit 4994a14
- netfilter: take a reference when looking up nft_sets
(bsc#1215420 CVE-2023-4244).
- commit 3f2e165
- netfilter: Implement reference counting for nft_sets
(bsc#1215420 CVE-2023-4244).
- commit b5c850d
- Fix the warning:
* return makes pointer from integer without a cast [enabled by default] in ../drivers/infiniband/hw/mlx5/srq.c in mlx5_ib_create_srq
../drivers/infiniband/hw/mlx5/srq.c: In function 'mlx5_ib_create_srq':
../drivers/infiniband/hw/mlx5/srq.c:259:3: warning: return makes pointer from integer without a cast [enabled by default]
- commit d292fa8
- x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK (git-fixes).
- commit 29d18ef
- fbdev: savage: Handle err return when savagefb_check_var failed (bsc#1227435 CVE-2024-39475)
- commit 3cf493f
- kgdb: Move the extern declaration kgdb_has_hit_break() to generic kgdb.h (git-fixes).
- commit 4c96601
- kgdb: Add kgdb_has_hit_break function (git-fixes).
- commit 096e8f7
- x86/ioremap: Fix page aligned size calculation in __ioremap_caller() (git-fixes).
- commit 51d4d78
- x86/numa: Use cpumask_available instead of hardcoded NULL check (git-fixes).
- commit 53fc2d1
- x86/msr: Fix wr/rdmsr_safe_regs_on_cpu() prototypes (git-fixes).
- commit 4cbd29b
- x86/fpu: Return proper error codes from user access functions (git-fixes).
- commit 16cc345
- x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs (git-fixes).
- commit 530272a
- x86/boot/e820: Fix typo in e820.c comment (git-fixes).
- commit 3e224a7
- x86/apic: Fix kernel panic when booting with intremap=off and x2apic_phys (git-fixes).
- commit f7c83aa
- x86: __memcpy_flushcache: fix wrong alignment if size > 2^32 (git-fixes).
- commit fe70714
- PM: hibernate: x86: Use crc32 instead of md5 for hibernation e820 integrity check (git-fixes).
- commit 63895f5
- can: pch_can: pch_can_rx_normal: fix use after free (bsc#1225431
CVE-2021-47520).
- commit 0efd10b
- wifi: nl80211: don't free NULL coalescing rule (bsc#1225835 CVE-2024-36941).
- commit 6927c00
- powerpc/rtas: Prevent Spectre v1 gadget construction in
sys_rtas() (bsc#1227487).
- commit 564651d
- SUNRPC: Fix loop termination condition in
gss_free_in_token_pages() (git-fixes).
- sunrpc: fix NFSACL RPC retry on soft mount (git-fixes).
- SUNRPC: Fix gss_free_in_token_pages() (git-fixes).
- nfs: Handle error of rpc_proc_register() in nfs_net_init()
(git-fixes).
- commit 823e515
- btrfs: do not BUG_ON in link_to_fixup_dir (bsc#1222005
CVE-2021-47145).
- commit fb0f08c
- soc: fsl: qbman: Use raw spinlock for cgr_lock (bsc#1224683
CVE-2024-35819).
- commit 4f6a315
- soc: fsl: qbman: Add CGR update function (bsc#1224683
CVE-2024-35819).
- commit 3b2ce3f
- soc: fsl: qbman: Add helper for sanity checking cgr ops
(bsc#1224683 CVE-2024-35819).
- commit b33b9fc
- soc: fsl: qbman: Always disable interrupts when taking cgr_lock
(bsc#1224683 CVE-2024-35819).
- commit 99e6ba5
- drm/amdgpu/debugfs: fix error code when smc register accessors are NULL (git-fixes).
- commit a2420fb
- sched/deadline: Fix BUG_ON condition for deboosted tasks
(bsc#1227407).
- commit 58fafac
- dyndbg: fix old BUG_ON in >control parser (bsc#1224647
CVE-2024-35947).
- commit 52ffbf7
- net: tulip: de4x5: fix the problem that the array 'lp->phy'
may be out of bound (bsc#1225505 CVE-2021-47547).
- commit 605a3ba
- drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL (CVE-2023-52817 bsc#1225569).
- commit d2e5a64
- drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga (CVE-2023-52819 bsc#1225532).
- commit d196cd8
- drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7 (CVE-2023-52818 bsc#1225530).
- commit d67dcd9
- drm/amd/display: Avoid NULL dereference of timing generator (CVE-2023-52753 bsc#1225478).
- commit f316fd9
- drm/arm/malidp: fix a possible null pointer dereference (CVE-2024-36014 bsc#1225593).
- commit 3f35223
- llc: make llc_ui_sendmsg() more robust against bonding changes
(CVE-2024-26636 bsc#1221659).
- commit 727fec1
- llc: Drop support for ETH_P_TR_802_2 (CVE-2024-26635
bsc#1221656).
- commit 4792924
- wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
(bsc#1224622 CVE-2024-35828).
- commit 9f39e76
- nfc: nci: assert requested protocol is valid (bsc#1220833, CVE-2023-52507).
- commit 78bd01e
- md: fix resync softlockup when bitmap size is less than array
size (CVE-2024-38598, bsc#1226757).
- commit e578184
- dm snapshot: fix lockup in dm_exception_table_exit (bsc#1224743,
CVE-2024-35805).
- dm: call the resume method on internal suspend (bsc#1223188,
CVE-2024-26880).
- dm rq: don't queue request to blk-mq during DM suspend
(bsc#1225357, CVE-2021-47498).
- bcache: avoid oversized read request in cache missing code path
(bsc#1224965, CVE-2021-47275).
- bcache: remove bcache device self-defined readahead
(bsc#1224965, CVE-2021-47275).
- commit 0df91b9
- net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove() (bsc#1225229 CVE-2021-47438)
- commit dd90392
- net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path (bsc#1225229 CVE-2021-47438)
- commit eebb92a
- usb-storage: alauda: Check whether the media is initialized
(CVE-2024-38619 bsc#1226861).
- commit 8f69e1a
- iavf: free q_vectors before queues in iavf_disable_vf
(CVE-2021-47201 bsc#1222792).
- commit 5fa75c2
- ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
(CVE-2024-26641 bsc#1221654).
- commit 785d6bf
- hsr: Fix uninit-value access in hsr_get_node() (bsc#1223021
CVE-2024-26863).
- net: hsr: fix placement of logical operator in a multi-line
statement (bsc#1223021).
- hsr: Fix uninit-value access in hsr_get_node() (bsc#1223021
CVE-2024-26863).
- net: hsr: fix placement of logical operator in a multi-line
statement (bsc#1223021).
- commit bea7af4
- ip6_tunnel: fix NEXTHDR_FRAGMENT handling in
ip6_tnl_parse_tlv_enc_lim() (CVE-2024-26633 bsc#1221647).
- commit 6bed746
- net: sock: preserve kabi for sock (bsc#1221010 CVE-2021-47103).
- commit 00f2734
- inet: fully convert sk->sk_rx_dst to RCU rules (bsc#1221010
CVE-2021-47103).
- commit 955aaf2
- watchdog: cpu5wdt.c: Fix use-after-free bug caused by
cpu5wdt_trigger (bsc#1226908 CVE-2024-38630).
- commit 4e6b95e
- Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
(bsc#1224177 CVE-2024-27399).
- commit f1f5272
- ACPI: processor_idle: Fix memory leak in
acpi_processor_power_exit() (bsc#1223043 CVE-2024-26894).
- commit 69014d4
- scsi: bnx2fc: Remove spin_lock_bh while releasing resources
after upload (bsc#1224767 CVE-2024-36919).
- scsi: lpfc: Move NPIV's transport unregistration to after
resource clean up (bsc#1225898 CVE-2024-36592).
- scsi: bnx2fc: Remove spin_lock_bh while releasing resources
after upload (bsc#1224767 CVE-2024-36919).
- scsi: lpfc: Move NPIV's transport unregistration to after
resource clean up (bsc#1225898 CVE-2024-36592).
- commit 011e140
- selinux: fix double free of cond_list on error paths
(bsc#1226699 CVE-2022-48740).
- commit c27761a
- fs/9p: fix uninitialized values during inode evict (bsc#1225815
CVE-2024-36923).
- commit fccda1c
- btrfs: fix crash on racing fsync and size-extending write into
prealloc (bsc#1227101 CVE-2024-37354).
- btrfs: add helper to truncate inode items when logging inode
(bsc#1227101 CVE-2024-37354).
- btrfs: don't set the full sync flag when truncation does not
touch extents (bsc#1227101 CVE-2024-37354).
- btrfs: fix misleading and incomplete comment of btrfs_truncate()
(bsc#1227101 CVE-2024-37354).
- btrfs: make btrfs_truncate_inode_items take btrfs_inode
(bsc#1227101 CVE-2024-37354).
- commit 25e24a4
- usb: typec: tcpm: Skip hard reset when in error recovery
(git-fixes).
- commit 74f41bf
- bpf, scripts: Correct GPL license name (git-fixes).
- commit d41908e
- Update
patches.suse/0006-dm-btree-remove-fix-use-after-free-in-rebalance_chil.patch
(git-fixes CVE-2021-47600 bsc#1226575).
- Update
patches.suse/PCI-pciehp-Fix-infinite-loop-in-IRQ-handler-upon-pow.patch
(git-fixes CVE-2021-47617 bsc#1226614).
- Update
patches.suse/USB-core-Fix-hang-in-usb_kill_urb-by-adding-memory-b.patch
(git-fixes CVE-2022-48760 bsc#1226712).
- Update
patches.suse/audit-improve-robustness-of-the-audit-queue-handling.patch
(bsc#1204514 CVE-2021-47603 bsc#1226577).
- Update
patches.suse/drm-vmwgfx-Fix-stale-file-descriptors-on-failed-user.patch
(CVE-2022-22942 bsc#1195065 CVE-2022-48771 bsc#1226732).
- Update patches.suse/igbvf-fix-double-free-in-igbvf_probe.patch
(git-fixes CVE-2021-47589 bsc#1226557).
- Update
patches.suse/isdn-cpai-check-ctr-cnr-to-avoid-array-index-out-of-bound.patch
(bsc#1191958 CVE-2021-43389 CVE-2021-4439 bsc#1226670).
- Update
patches.suse/net-ieee802154-ca8210-Stop-leaking-skb-s.patch
(git-fixes CVE-2022-48722 bsc#1226619).
- Update
patches.suse/netfilter-complete-validation-of-user-input.patch
(git-fixes CVE-2024-35896 bsc#1224662 CVE-2024-35962
bsc#1224583).
- Update patches.suse/phylib-fix-potential-use-after-free.patch
(bsc#1119113 FATE#326472 CVE-2022-48754 bsc#1226692).
- Update
patches.suse/ring-buffer-Fix-a-race-between-readers-and-resize-checks.patch
(bsc#1222893 CVE-2024-38601 bsc#1226876).
- Update
patches.suse/scsi-bnx2fc-Flush-destroy_work-queue-before-calling-bnx2fc_interface_put
(git-fixes CVE-2022-48758 bsc#1226708).
- Update patches.suse/scsi-bnx2fc-Make-bnx2fc_recv_frame-mp-safe
(git-fixes CVE-2022-48715 bsc#1226621).
- Update
patches.suse/scsi-libfc-Fix-potential-NULL-pointer-dereference-in-fc_lport_ptp_setup.patch
(git-fixes CVE-2023-52809 bsc#1225556).
- Update
patches.suse/scsi-qla2xxx-Fix-off-by-one-in-qla_edif_app_getstats.patch
(git-fixes CVE-2024-36025 bsc#1225704).
- Update
patches.suse/scsi-scsi_debug-Sanity-check-block-descriptor-length-in-resp_mode_select
(git-fixes CVE-2021-47576 bsc#1226537).
- Update
patches.suse/scsi-target-core-Add-TMF-to-tmr_list-handling.patch
(bsc#1223018 CVE-26845 CVE-2024-26845).
- Update
patches.suse/tipc-improve-size-validations-for-received-domain-re.patch
(bsc#1195254 CVE-2022-0435 CVE-2022-48711 bsc#1226672).
- commit c2edf0b
- tcp: do not accept ACK of bytes we never sent (CVE-2023-52881
bsc#1225611).
- commit d93d95b
- usb: port: Don't try to peer unused USB ports based on location
(git-fixes).
- commit c96b5c5
- x86/tsc: Trust initial offset in architectural TSC-adjust MSRs
(bsc#1222015 bsc#1226962).
- commit c9f769c
- iommu/vt-d: Allocate local memory for page request queue
(git-fixes).
- commit 541ce64
- iommu/amd: Fix sysfs leak in iommu init (git-fixes).
- commit cdae1dd
- KVM: x86: Handle SRCU initialization failure during page track
init (CVE-2021-47407, bsc#1225306).
- commit 61b3e37
- xen/events: close evtchn after mapping cleanup (CVE-2024-26687,
bsc#1222435).
- commit c56fe01
- net/9p: fix uninit-value in p9_client_rpc() (CVE-2024-39301 bsc#1226994).
- commit 1a033be
- media: lgdt3306a: Add a check against null-pointer-def
(CVE-2022-48772 bsc#1226976).
- commit 79e986b
- fpga: manager: add owner module and take its refcount
(CVE-2024-37021 bsc#1226950).
- commit 580ed12
- fpga: region: add owner module and take its refcount
(CVE-2024-35247 bsc#1226948).
- commit 75fbd8f
- fpga: bridge: add owner module and take its refcount
(CVE-2024-36479 bsc#1226949).
- commit 410068f
- enic: Validate length of nl attributes in enic_set_vf_port
(CVE-2024-38659 bsc#1226883).
- net: fec: remove .ndo_poll_controller to avoid deadlocks
(CVE-2024-38553 bsc#1226744).
- net/mlx5e: Fix netif state handling (CVE-2024-38608
bsc#1226746).
- eth: sungem: remove .ndo_poll_controller to avoid deadlocks
(CVE-2024-38597 bsc#1226749).
- net: amd-xgbe: Fix skb data length underflow (CVE-2022-48743
bsc#1226705).
- net: systemport: Add global locking for descriptor lifecycle
(CVE-2021-47587 bsc#1226567).
- commit 6fa5a1e
- usb: xhci-plat: fix crash when suspend if remote wake enable
(CVE-2022-48761 bsc#1226701).
- commit 6918857
- virtio-blk: fix implicit overflow on virtio_max_dma_size
(bsc#1225573 CVE-2023-52762).
- commit 630807b
- btrfs: fix use-after-free after failure to create a snapshot
(bsc#1226718 CVE-2022-48733).
- commit bc8f6e2
- vfio/platform: Create persistent IRQ handlers (bsc#1222809
CVE-2024-26813).
- commit a912042
- Update to fix a compiling error,
patches.suse/raid1-fix-use-after-free-for-original-bio-in-raid1_-fcf3.patch.
- commit 4738bf0
- s390/ap: Fix crash in AP internal function modify_bitmap()
(CVE-2024-38661 bsc#1226996 git-fixes).
- commit 642fe77
- block: fix overflow in blk_ioctl_discard() (bsc#1225770
CVE-2024-36917).
- commit fb1867c
- epoll: be better about file lifetimes (bsc#1226610
CVE-2024-38580).
- commit da86de7
- KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond (git-fixes).
- commit 63ce06d
- drm/nouveau: fix off by one in BIOS boundary checking (bsc#1226716 CVE-2022-48732)
- commit bed5212
- Update references tag
patches.suse/Bluetooth-Disconnect-if-E0-is-used-for-Level-4.patch
(bsc#1171988 CVE-2020-10135 bsc#1218148 CVE-2023-24023).
- commit b41c397
- mm: Avoid overflows in dirty throttling logic (bsc#1222364
CVE-2024-26720).
- commit 6f98632
- media: stk1160: fix bounds checking in stk1160_copy_video()
(CVE-2024-38621 bsc#1226895).
- commit 617f122
- dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
(CVE-2024-38780 bsc#1226886).
- commit 0a1e3b6
- nvmet: fix ns enable/disable possible hang (git-fixes).
- commit 128ca3f
- ecryptfs: Fix buffer size for tag 66 packet (bsc#1226634, CVE-2024-38578).
- commit 41891c0
- stm class: Fix a double free in stm_register_device()
(CVE-2024-38627 bsc#1226857).
- commit b4ea481
- crypto: bcm - Fix pointer arithmetic (bsc#1226637
CVE-2024-38579).
- commit be1545d
- drm/amd/display: Fix potential index out of bounds in color (bsc#1226767 CVE-2024-38552)
- commit fdaaa54
- drm/mediatek: Add 0 size check to mtk_drm_gem_obj (bsc#1226735 CVE-2024-38549)
- commit b67d29d
- drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable (bsc#1226698 CVE-2022-48756)
- commit bd95a05
- net: usb: rtl8150 fix unintiatilzed variables in
rtl8150_get_link_ksettings (git-fixes).
- commit 996e5c4
- RDMA/hns: Fix UAF for cq async event (bsc#1226595 CVE-2024-38545)
- commit 68cd4b9
- RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt (bsc#1226597 CVE-2024-38544)
- commit da8c605
- RDMA/mlx5: Add check for srq max_sge attribute (git-fixes)
- commit 6ee55be
- drm: vc4: Fix possible null pointer dereference (CVE-2024-38546
bsc#1226593).
- commit f5c6e94
- wifi: carl9170: add a proper sanity check for endpoints
(CVE-2024-38567 bsc#1226769).
- rpmsg: char: Fix race between the release of rpmsg_ctrldev
and cdev (CVE-2022-48759 bsc#1226711).
- commit 1d933f6
- wifi: ar5523: enable proper endpoint verification
(CVE-2024-38565 bsc#1226747).
- commit 7f113b6
- mac80211: track only QoS data frames for admission control
(CVE-2021-47602 bsc#1226554).
- commit 6d84852
- ALSA: timer: Set lower bound of start tick time (CVE-2024-38618
bsc#1226754).
- commit ea3c02c
- bsc#1225894: Fix build warning
Fix the following build warning.
* unused-variable (i) in ../drivers/gpu/drm/amd/amdkfd/kfd_device.c in kgd2kfd_resume
../drivers/gpu/drm/amd/amdkfd/kfd_device.c: In function 'kgd2kfd_resume':
../drivers/gpu/drm/amd/amdkfd/kfd_device.c:621:11: warning: unused variable 'i' [-Wunused-variable]
- commit e16e5ba
- bsc#1225894: Fix patch references
- commit 7b4670a
- net/mlx5: Properly link new fs rules into the tree (bsc#1224588
CVE-2024-35960).
- commit 14f14ea
- net/mlx5e: fix a double-free in arfs_create_groups (bsc#1224605
CVE-2024-35835).
- commit 2cc5781
- firmware: arm_scpi: Fix string overflow in SCPI genpd driver (bsc#1226562 CVE-2021-47609)
- commit 4642449
- Fix compilation
- commit 3f5119e
- net: ena: Fix incorrect descriptor free behavior (bsc#1224677
CVE-2024-35958).
- commit 8f4768d
- bonding: stop the device in bond_setup_by_slave() (bsc#1224946
CVE-2023-52784).
- commit da74b6f
- scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
(bsc#1224651 CVE-2024-35930).
- scsi: target: core: Add TMF to tmr_list handling (bsc#1223018
CVE-26845).
- scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()
(bsc#122286 CVE-2021-47191).
- commit 3100b52
- usb: fix various gadget panics on 10gbps cabling (CVE-2021-47267
bsc#1224993).
- commit 3336e4a
- amd/amdkfd: sync all devices to wait all processes being evicted (bsc#1225872 CVE-2024-36949)
- commit aa91737
- drm/amdkfd: Rework kfd_locked handling (bsc#1225872)
- commit 030a69d
- drm/vmwgfx: Fix invalid reads in fence signaled events (bsc#1225872 CVE-2024-36960)
- commit fe8da4d
- nfsd: optimise recalculate_deny_mode() for a common case
(bsc#1217912).
- commit 90c611c
- NFSv4: Always clear the pNFS layout when handling ESTALE
(bsc#1221791).
- NFSv4: nfs_set_open_stateid must not trigger state recovery
for closed state (bsc#1221791).
- PNFS for stateid errors retry against MDS first (bsc#1221791).
- commit fcd364d
- block: prevent division by zero in blk_rq_stat_sum()
(bsc#1224661 CVE-2024-35925).
- commit 7fd346a
- ext4: fix corruption during on-line resize (bsc#1224735
CVE-2024-35807).
- commit 8431549
- fat: fix uninitialized field in nostale filehandles (git-fixes
CVE-2024-26973 bsc#1223641).
- commit 8b4f3fd
- ext4: avoid online resizing failures due to oversized flex bg
(bsc#1222080 CVE-2023-52622).
- commit a81bee5
- net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()
(CVE-2021-47559 bsc#1225396).
- commit ca251c9
- nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done
(CVE-2021-47518 bsc#1225372).
- commit d0fabf7
- net_sched: fix NULL deref in fifo_set_limit()
(CVE-2021-47418 bsc#1225337).
- commit 54048d4
- net: validate lwtstate->data before returning from skb_tunnel_info()
(CVE-2021-47309 bsc#1224967).
- commit 2b76537
- net: fix uninit-value in caif_seqpkt_sendmsg
(CVE-2021-47297 bsc#1224976).
- commit 39164d4
- net/sched: act_skbmod: Skip non-Ethernet packets
(CVE-2021-47293 bsc#1224978).
- commit aedefe0
- netrom: Decrease sock refcount when sock timers expire
(CVE-2021-47294 bsc#1224977).
- commit 44bce11
- ipv6: Fix infinite recursion in fib6_dump_done() (CVE-2024-35886
bsc#1224670).
- commit 5d20998
- tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
(CVE-2024-36016 bsc#1225642).
- commit f5c4f31
- net: macb: fix use after free on rmmod (CVE-2021-47372
bsc#1225184).
- commit 5bb5ee7
- btrfs: use correct compare function of dirty_metadata_bytes (git-fixes)
- commit d51a7ff
- Btrfs: fix memory and mount leak in btrfs_ioctl_rm_dev_v2() (git-fixes)
- commit 4b455f0
- btrfs: fix describe_relocation when printing unknown flags (git-fixes)
- commit a147519
- btrfs: add barriers to btrfs_sync_log before log_commit_wait wakeups (git-fixes)
- commit 0487247
- btrfs: fix crash when trying to resume balance without the resume flag (git-fixes)
- commit f0fa7bc
- Btrfs: clean up resources during umount after trans is aborted (git-fixes)
- commit c78d131
- Btrfs: bail out on error during replay_dir_deletes (git-fixes)
- commit 7a8f6ce
- Btrfs: fix NULL pointer dereference in log_dir_items (git-fixes)
- commit 02cab92
- Btrfs: send, fix issuing write op when processing hole in no data mode (git-fixes)
- Refresh
patches.suse/btrfs-send-fix-incorrect-file-layout-after-hole-punching-beyond-eof.patch.
- commit f710800
- Btrfs: fix unexpected EEXIST from btrfs_get_extent (git-fixes)
- commit 82c1e6b
- btrfs: tree-check: reduce stack consumption in check_dir_item (git-fixes)
- commit 36aca35
- btrfs: fix false EIO for missing device (git-fixes)
- Refresh
patches.suse/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch
- commit 01544ea
- USB: serial: option: add Quectel EG912Y module support
(git-fixes).
- commit a8d3e25
- USB: serial: option: add Quectel RM500Q R13 firmware support
(git-fixes).
- commit b3dedc2
- USB: serial: option: add Foxconn T99W265 with new baseline
(git-fixes).
- commit 51f747d
- net: usb: smsc95xx: fix changing LED_SEL bit value updated
from EEPROM (git-fixes).
- commit d6ed297
- ocfs2: fix sparse warnings (bsc#1219224).
- ocfs2: speed up chain-list searching (bsc#1219224).
- ocfs2: adjust enabling place for la window (bsc#1219224).
- ocfs2: improve write IO performance when fragmentation is high
(bsc#1219224).
- commit d862a97
- smb: client: fix use-after-free bug in
cifs_debug_data_proc_show() (bsc#1225487, CVE-2023-52752).
- commit b2bff17
- blkcg: Fix multiple bugs in blkcg_activate_policy()
(CVE-2021-47379 bsc#1225203).
- blkcg: blkcg_activate_policy() should initialize ancestors first
(CVE-2021-47379 bsc#1225203).
- commit 5e6941f
- blk-cgroup: fix UAF by grabbing blkcg lock before destroying
blkg pd (CVE-2021-47379 bsc#1225203).
- commit 26f8206
- atl1c: Work around the DMA RX overflow issue (CVE-2023-52834
bsc#1225599).
- commit c880bf0
- btrfs: lock the inode in shared mode before starting fiemap
(bsc#1225484 CVE-2023-52737).
- commit e4a79d3
- ext4: correct offset of gdb backup in non meta_bg group to
update_backups (bsc#1224735 CVE-2024-35807).
- commit 57ba8ce
- raid1: fix use-after-free for original bio in raid1_write_request()
(bsc#1221097, bsc#1224572, CVE-2024-35979).
- commit daf8372
- fs/9p: only translate RWX permissions for plain 9P2000
(bsc#1225866 CVE-2024-36964).
- commit 7cf061b
- media: imon: fix access to invalid resource for the second
interface (CVE-2023-52754 bsc#1225490).
- commit 0f818a4
- firewire: ohci: mask bus reset interrupts between ISR and
bottom half (CVE-2024-36950 bsc#1225895).
- commit 342de59
- pinctrl: core: delete incorrect free in pinctrl_enable()
(CVE-2024-36940 bsc#1225840).
- commit 6103cd4
- staging: rtl8192e: Fix use after free in
_rtl92e_pci_disconnect() (CVE-2021-47571 bsc#1225518).
- commit 9243acc
- media: gspca: cpia1: shift-out-of-bounds in set_flicker
(CVE-2023-52764 bsc#1225571).
- wifi: mac80211: don't return unset power in
ieee80211_get_tx_power() (CVE-2023-52832 bsc#1225577).
- commit 74cf739
- Bluetooth: qca: add missing firmware sanity checks
(CVE-2024-36880 bsc#1225722).
- commit 1f313de
- drm/msm: Fix null pointer dereference on pointer edp (bsc#1225261 CVE-2021-47445)
- commit 7365fdb
- rpm/kernel-obs-build.spec.in: Add iso9660 (bsc#1226212)
Some builds don't just create an iso9660 image, but also mount it during
build.
- commit aaee141
- llc: verify mac len before reading mac header
(CVE-2023-52843 bsc#1224951).
- commit 048fdd1
- drm/sched: Avoid data corruptions (bsc#1225140 CVE-2021-47354)
- commit 735d57e
- nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies
(CVE-2024-36915 bsc#1225758).
- commit d2aa3fc
- rpm/kernel-obs-build.spec.in: Add networking modules for docker
(bsc#1226211)
docker needs more networking modules, even legacy iptable_nat and _filter.
- commit 415e132
- Bluetooth: Add more enc key size check (bsc#1218148
CVE-2023-24023).
- commit 8b7d4c7
- rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
(CVE-2024-36017 bsc#1225681).
- commit eee2828
- netfilter: complete validation of user input
(git-fixes CVE-2024-35896 bsc#1224662).
- commit bd2bc6c
- tcp: fix page frag corruption on page fault
(CVE-2021-47544 bsc#1225463).
- commit 0c69f93
- netfilter: validate user input for expected length
(CVE-2024-35896 bsc#1224662).
- commit d09d89a
- Bluetooth: Normalize HCI_OP_READ_ENC_KEY_SIZE cmdcmplt
(bsc#1218148 CVE-2023-24023).
- commit be61b35
- arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
(git-fixes).
- commit a33c0aa
- fbmon: prevent division by zero in fb_videomode_from_videomode() (bsc#1224660 CVE-2024-35922)
- commit 9990cdc
- bna: ensure the copied buf is NUL terminated (CVE-2024-36934
bsc#1225760).
- commit 5e5c793
- tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
(CVE-2023-52845 bsc#1225585).
- commit 28beea5
- HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent
lock-up (bsc#1224552 CVE-2024-35997).
- commit 31522d3
- wifi: nl80211: reject iftype change with mesh ID change
(CVE-2024-27410 bsc#1224432).
- commit 18882c6
- fix compat handling of FICLONERANGE, FIDEDUPERANGE and
FS_IOC_FIEMAP (bsc#1225848).
- blacklist.conf:
- fs: make fiemap work from compat_ioctl (bsc#1225848).
- commit e6c580c
- perf/core: Bail out early if the request AUX area is out of
bound (bsc#1225602 CVE-2023-52835).
- commit 0b197bf
- powerpc/imc-pmu: Add a null pointer check in
update_events_in_group() (bsc#1224504 CVE-2023-52675).
- commit 5ed0541
- usb: gadget: f_fs: Fix race between aio_cancel() and AIO
request complete (CVE-2024-36894 bsc#1225749).
- commit 66229f2
- proc/vmcore: fix clearing user buffer by properly using
clear_user() (CVE-2021-47566 bsc#1225514).
- commit 4f35255
- usb: dwc2: fix possible NULL pointer dereference caused by
driver concurrency (CVE-2023-52855 bsc#1225583).
- commit 304ea43
- Refresh patches.kabi/net-preserve-kabi-for-sk_buff.patch.
- commit fa7929b
- net: preserve kabi for sk_buff (CVE-2024-26921 bsc#1223138).
- commit 726f363
- inet: inet_defrag: prevent sk release while still in use
(CVE-2024-26921 bsc#1223138).
- commit 7846939
- xhci: Fix commad ring abort, write all 64 bits to CRCR register
(CVE-2021-47434 bsc#1225232).
- commit d92fac3
- xhci: Fix command ring pointer corruption while aborting a
command (CVE-2021-47434 bsc#1225232).
- blacklist.conf: taken so that the correct fix applies
- commit ea90837
- xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
(bsc#1224575 CVE-2024-35976).
- commit 641c7c4
- usb: fix various gadgets null ptr deref on 10gbps cabling
(CVE-2021-47270 bsc#1224997).
- commit 00c58e2
- usb: udc: remove warning when queue disabled ep (CVE-2024-35822
bsc#1224739).
- commit dcaf30a
- bpf, skmsg: Fix NULL pointer dereference in
sk_psock_skb_ingress_enqueue (bsc#1225761 CVE-2024-36938).
- commit 24fab08
- drm/client: Fully protect modes with dev->mode_config.mutex (CVE-2024-35950 bsc#1224703).
- commit f0cb811
- smb: client: fix potential deadlock when releasing mids
(bsc#1225548, CVE-2023-52757).
- commit 00dc86e
- smb: client: fix potential UAF in is_valid_oplock_break()
(bsc#1224763, CVE-2024-35863).
- commit be79366
- smb: client: fix potential UAF in cifs_stats_proc_write()
(bsc#1224678, CVE-2024-35868).
- commit 7c5946d
- smb: client: fix potential UAF in cifs_stats_proc_show()
(bsc#1224664, CVE-2024-35867).
- commit adb391f
- smb: client: fix potential UAF in cifs_debug_files_proc_show()
(bsc#1223532, CVE-2024-26928).
- commit 92bb153
- smb: client: fix UAF in smb2_reconnect_server() (bsc#1224672,
CVE-2024-35870).
- commit 4eabe16
- smb: client: fix potential UAF in smb2_is_valid_lease_break()
(bsc#1224765, CVE-2024-35864).
- commit 688ad5f
- smb: client: fix potential UAF in smb2_is_network_name_deleted()
(bsc#1224764, CVE-2024-35862).
- commit 6bbd54b
- smb3: fix lock ordering potential deadlock in
cifs_sync_mid_result (bsc#1224549, CVE-2024-35998).
- commit fbe7cb6
- smb: client: fix potential UAF in smb2_is_valid_oplock_break()
(bsc#1224668, CVE-2024-35865).
- commit 77a46ab
- nvme-tcp: fix UAF when detecting digest errors (CVE-2022-48686 bsc#1223948).
Update blacklist.conf: remove entry
- commit f159215
- nvme-loop: fix memory leak in nvme_loop_create_ctrl() (CVE-2021-47074 bsc#1220854).
Update blacklist.conf: remove entry
- commit 5f6a5df
- nvme-rdma: destroy cm id before destroy qp to avoid use after
free (CVE-2021-47378 bsc#1225201).
- commit 599a36a
- nvmet: fix a use-after-free (CVE-2022-48697 bsc#1223922).
Update blacklist.conf: drop entry from it
- commit 5e496a4
- nvme-fc: do not wait in vain when unloading module
(CVE-2024-26846 bsc#1223023).
- commit 365a6dd
- net/tls: Fix flipped sign in tls_err_abort() calls
(CVE-2021-47496 bsc#1225354)
- commit af28ae7
- Update
patches.suse/0004-dm-fix-mempool-NULL-pointer-race-when-completing-IO.patch
(git-fixes bsc#1225247 CVE-2021-47435).
- Update
patches.suse/0022-dm-btree-remove-assign-new_root-only-when-removal-su.patch
(git fixes bsc#1225155 CVE-2021-47343).
- Update
patches.suse/0066-virtio-blk-Fix-memory-leak-among-suspend-resume-procedure.patch
(git-fixes bsc#1225054 CVE-2021-47319).
- Update
patches.suse/HID-betop-fix-slab-out-of-bounds-Write-in-betop_prob.patch
(git-fixes bsc#1207186 bsc#1225303 CVE-2021-47404).
- Update
patches.suse/IB-hfi1-Fix-leak-of-rcvhdrtail_dummy_kvaddr.patch
(git-fixes bsc#1225438 CVE-2021-47523).
- Update
patches.suse/IB-mlx5-Fix-initializing-CQ-fragments-buffer.patch
(git-fixes bsc#1224954 CVE-2021-47261).
- Update
patches.suse/IB-qib-Protect-from-buffer-overflow-in-struct-qib_us.patch
(git-fixes bsc#1224904 CVE-2021-47485).
- Update
patches.suse/RDMA-cma-Ensure-rdma_addr_cancel-happens-before-issu.patch
(git-fixes bsc#1225318 CVE-2021-47391).
- Update
patches.suse/RDMA-cma-Fix-rdma_resolve_route-memory-leak.patch
(git-fixes bsc#1225157 CVE-2021-47345).
- Update
patches.suse/SUNRPC-Fix-RPC-client-cleaned-up-the-freed-pipefs-de.patch
(git-fixes bsc#1225008 CVE-2023-52803).
- Update
patches.suse/blktrace-Fix-uaf-in-blk_trace-access-after-removing-.patch
(bsc#1191452 bsc#1225193 CVE-2021-47375).
- Update patches.suse/can-peak_pci-peak_pci_remove-fix-UAF.patch
(git-fixes bsc#1225256 CVE-2021-47456).
- Update
patches.suse/cifs-Fix-use-after-free-in-rdata-read_into_pages-.patch
(bsc#1190317 bsc#1225479 CVE-2023-52741).
- Update
patches.suse/cifs-prevent-NULL-deref-in-cifs_compose_mount_options-.patch
(bsc#1185902 bsc#1224961 CVE-2021-47307).
- Update
patches.suse/dma-buf-sync_file-Don-t-leak-fences-on-merge-failure.patch
(git-fixes bsc#1224968 CVE-2021-47305).
- Update
patches.suse/drm-Fix-use-after-free-read-in-drm_getunique.patch
(git-fixes bsc#1224982 CVE-2021-47280).
- Update
patches.suse/ftrace-Do-not-blindly-read-the-ip-address-in-ftrace_bug.patch
(git-fixes bsc#1224966 CVE-2021-47276).
- Update patches.suse/gfs2-ignore-negated-quota-changes.patch
(git-fixes bsc#1225560 CVE-2023-52759).
- Update
patches.suse/i40e-Fix-freeing-of-uninitialized-misc-IRQ-vector.patch
(bsc#1101816 FATE#325147 FATE#325149 bsc#1225367
CVE-2021-47424).
- Update
patches.suse/igb-Fix-use-after-free-error-during-reset.patch
(git-fixes bsc#1224916 CVE-2021-47301).
- Update
patches.suse/igc-Fix-use-after-free-error-during-reset.patch
(git-fixes bsc#1224917 CVE-2021-47302).
- Update
patches.suse/ipv4-ipv6-Fix-handling-of-transhdrlen-in-__ip-6-_app.patch
(git-fixes bsc#1220928 CVE-2023-52527).
- Update
patches.suse/isdn-mISDN-netjet-Fix-crash-in-nj_probe.patch
(git-fixes bsc#1224987 CVE-2021-47284).
- Update
patches.suse/isofs-Fix-out-of-bound-access-for-corrupted-isofs-im.patch
(bsc#1194591 bsc#1225198 CVE-2021-47478).
- Update
patches.suse/kprobes-Fix-possible-use-after-free-issue-on-kprobe-registration.patch
(git-fixes bsc#1224676 CVE-2024-35955).
- Update
patches.suse/l2tp-pass-correct-message-length-to-ip6_append_data.patch
(git-fixes bsc#1222667 CVE-2024-26752).
- Update
patches.suse/mISDN-fix-possible-use-after-free-in-HFC_cleanup.patch
(git-fixes bsc#1225143 CVE-2021-47356).
- Update
patches.suse/media-zr364xx-fix-memory-leak-in-zr364xx_start_readp.patch
(git-fixes bsc#1224922 CVE-2021-47344).
- Update
patches.suse/net-USB-Fix-wrong-direction-WARNING-in-plusb.c.patch
(git-fixes bsc#1225482 CVE-2023-52742).
- Update
patches.suse/net-hns3-do-not-allow-call-hns3_nic_net_open-repeate.patch
(git-fixes bsc#1225329 CVE-2021-47400).
- Update
patches.suse/net-mdiobus-Fix-memory-leak-in-__mdiobus_register.patch
(git-fixes bsc#1225189 CVE-2021-47472).
- Update
patches.suse/net-mlx4_en-Fix-an-use-after-free-bug-in-mlx4_en_try.patch
(git-fixes bsc#1225453 CVE-2021-47541).
- Update
patches.suse/net-nfc-rawsock.c-fix-a-permission-check-bug.patch
(git-fixes bsc#1224981 CVE-2021-47285).
- Update patches.suse/net-qcom-emac-fix-UAF-in-emac_remove.patch
(git-fixes bsc#1225010 CVE-2021-47311).
- Update patches.suse/net-ti-fix-UAF-in-tlan_remove_one.patch
(git-fixes bsc#1224959 CVE-2021-47310).
- Update
patches.suse/net-usb-kalmia-Don-t-pass-act_len-in-usb_bulk_msg-er.patch
(git-fixes bsc#1225549 CVE-2023-52703).
- Update
patches.suse/nfs-fix-acl-memory-leak-of-posix_acl_create.patch
(git-fixes bsc#1225058 CVE-2021-47320).
- Update
patches.suse/nfsd-fix-use-after-free-due-to-delegation-race.patch
(git-fixes bsc#1225404 CVE-2021-47506).
- Update
patches.suse/ocfs2-fix-data-corruption-after-conversion-from-inli.patch
(bsc#1190795 bsc#1225251 CVE-2021-47460).
- Update
patches.suse/ocfs2-mount-fails-with-buffer-overflow-in-strlen.patch
(bsc#1197760 bsc#1225252 CVE-2021-47458).
- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
bsc#1225336 CVE-2021-47416).
- Update
patches.suse/ppdev-Add-an-error-check-in-register_device.patch
(git-fixes bsc#1225640 CVE-2024-36015).
- Update
patches.suse/s390-dasd-protect-device-queue-against-concurrent-access.patch
(git-fixes bsc#1217519 bsc#1225572 CVE-2023-52774).
- Update
patches.suse/s390-qeth-fix-NULL-deref-in-qeth_clear_working_pool_list
(git-fixes bsc#1225164 CVE-2021-47369).
- Update
patches.suse/s390-qeth-fix-deadlock-during-failing-recovery
(bsc#1206213 LTC#200742 bsc#1225207 CVE-2021-47382).
- Update
patches.suse/scsi-core-Fix-bad-pointer-dereference-when-ehandler-kthread-is-invalid
(git-fixes bsc#1224926 CVE-2021-47337).
- Update
patches.suse/scsi-core-Put-LLD-module-refcnt-after-SCSI-device-is-released
(git-fixes bsc#1225322 CVE-2021-47480).
- Update
patches.suse/scsi-libfc-Fix-array-index-out-of-bound-exception.patch
(bsc#1188616 bsc#1224963 CVE-2021-47308).
- Update
patches.suse/scsi-mpt3sas-Fix-kernel-panic-during-drive-powercycle-test
(git-fixes bsc#1225384 CVE-2021-47565).
- Update
patches.suse/scsi-qla2xxx-Fix-a-memory-leak-in-an-error-path-of-qla2x00_process_els
(git-fixes bsc#1225192 CVE-2021-47473).
- Update
patches.suse/tipc-fix-a-possible-memleak-in-tipc_buf_append.patch
(bsc#1221977 CVE-2021-47162 bsc#1225764 CVE-2024-36954).
- Update
patches.suse/tracing-Correct-the-length-check-which-causes-memory-corruption.patch
(git-fixes bsc#1224990 CVE-2021-47274).
- Update
patches.suse/tracing-trigger-Fix-to-return-error-if-failed-to-alloc-snapshot.patch
(git-fixes CVE-2024-26920).
- Update
patches.suse/tty-n_gsm-require-CAP_NET_ADMIN-to-attach-N_GSM0710-.patch
(bsc#1222619 CVE-2023-52880).
- Update
patches.suse/tty-serial-8250-serial_cs-Fix-a-memory-leak-in-error.patch
(git-fixes bsc#1225084 CVE-2021-47330).
- Update
patches.suse/udf-Fix-NULL-pointer-dereference-in-udf_symlink-func.patch
(bsc#1206646 bsc#1225128 CVE-2021-47353).
- Update
patches.suse/usb-config-fix-iteration-issue-in-usb_get_bos_descri.patch
(git-fixes bsc#1225092 CVE-2023-52781).
- Update
patches.suse/usb-dwc2-check-return-value-after-calling-platform_g.patch
(git-fixes bsc#1225330 CVE-2021-47409).
- Update
patches.suse/usb-dwc3-ep0-fix-NULL-pointer-exception.patch
(git-fixes bsc#1224996 CVE-2021-47269).
- Update patches.suse/usb-musb-dsps-Fix-the-probe-error-path.patch
(git-fixes bsc#1225244 CVE-2021-47436).
- Update patches.suse/usbnet-sanity-check-for-maxpacket.patch
(git-fixes bsc#1225351 CVE-2021-47495).
- Update
patches.suse/watchdog-Fix-possible-use-after-free-by-calling-del_.patch
(git-fixes bsc#1225060 CVE-2021-47321).
- Update
patches.suse/watchdog-Fix-possible-use-after-free-in-wdt_startup.patch
(git-fixes bsc#1225030 CVE-2021-47324).
- Update
patches.suse/watchdog-sc520_wdt-Fix-possible-use-after-free-in-wd.patch
(git-fixes bsc#1225026 CVE-2021-47323).
- Update
patches.suse/wl1251-Fix-possible-buffer-overflow-in-wl1251_cmd_sc.patch
(git-fixes bsc#1225177 CVE-2021-47347).
- commit 8975a47
- powerpc/pseries/lparcfg: drop error message from guest name
lookup (bsc#1187716 ltc#193451 git-fixes).
- commit 62b0891
- netfilter: nft_compat: explicitly reject ERROR and standard
target (git-fixes).
- commit 46fdab6
- netfilter: x_tables: set module owner for icmp(6) matches
(git-fixes).
- commit 8835e2a
- netfilter: nf_queue: augment nfqa_cfg_policy (git-fixes).
- commit d5734cd
- rds: avoid unenecessary cong_update in loop transport
(git-fixes).
- commit 758da4a
- cls_rsvp: check user supplied offsets (CVE-2023-42755
bsc#1215702).
- commit b722f7c
- l2tp: pass correct message length to ip6_append_data
(git-fixes).
- commit 5edafdb
- net: 9p: avoid freeing uninit memory in p9pdu_vreadf
(git-fixes).
- commit fdb6a12
- wifi: cfg80211: avoid leaking stack data into trace (git-fixes).
- commit 58724e2
- ipv4, ipv6: Fix handling of transhdrlen in
__ip{,6}_append_data() (git-fixes).
- commit 7f0cb3d
- rxrpc: Fix a memory leak in rxkad_verify_response() (git-fixes).
- commit 301026e
- wifi: radiotap: fix kernel-doc notation warnings (git-fixes).
- commit a96badd
- net: tcp: fix unexcepted socket die when snd_wnd is 0
(git-fixes).
- commit 66b602a
- tcp: tcp_make_synack() can be called from process context
(git-fixes).
- commit 1171bb0
- net/smc: fix fallback failed while sendmsg with fastopen
(git-fixes).
- commit 85612f4
- nfc: change order inside nfc_se_io error path (git-fixes).
- commit 92d40f5
- ila: do not generate empty messages in
ila_xlat_nl_cmd_get_mapping() (git-fixes).
- commit bd4b08a
- rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp
(git-fixes).
- commit 30e8bf8
- rxrpc: Work around usercopy check (git-fixes).
- commit f1a8d7a
- rxrpc: Don't put crypto buffers on the stack (git-fixes).
- commit d4118f5
- rxrpc: Provide a different lockdep key for call->user_mutex
for kernel calls (git-fixes).
- commit 256d44f
- rxrpc: The mutex lock returned by rxrpc_accept_call() needs
releasing (git-fixes).
- commit 56d0a26
- net: atlantic: eliminate double free in error handling logic
(CVE-2023-52664 bsc#1224747).
- ipvlan: add ipvlan_route_v6_outbound() helper (CVE-2023-52796
bsc#1224930).
- net/mlx5e: Fix page reclaim for dead peer hairpin
(CVE-2021-47246 bsc#1224831).
- commit e8481e2
- ceph: blocklist the kclient when receiving corrupted snap trace
(bsc#1225222 CVE-2023-52732).
- commit afa0bf6
- btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() (CVE-2024-35936 bsc#1224644)
- commit 7904756
- btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() (CVE-2024-35936 bsc#1224644)
- commit 64d6920
- ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array (bsc#1225506 CVE-2021-47548)
- commit e4002ca
- mmc: sdhci-msm: pervent access to suspended controller (bsc#1225708 CVE-2024-36029)
- commit 0915583
- llc: call sock_orphan() at release time
(CVE-2024-26625 bsc#1221086)
- commit 1715209
- virtio-net: Add validation for used length (CVE-2021-47352
bsc#1225124).
- commit 91c03a8
- calipso: fix memory leak in netlbl_calipso_add_pass()
(CVE-2023-52698 bsc#1224621)
- commit 008f52c
- ppdev: Add an error check in register_device (git-fixes).
- commit d524561
- drm/amdgpu: fix gart.bo pin_count leak (CVE-2021-47431 bsc#1225390).
- commit 1e38f4d
- btrfs: send: handle path ref underflow in header iterate_inode_ref() (CVE-2024-35935 bsc#1224645)
- commit 0b2d17e
- smb: client: fix potential OOBs in smb2_parse_contexts()
(bsc#1220148, CVE-2023-52434).
- commit e0971fe
- cifs: fix underflow in parse_server_interfaces() (bsc#1223084,
CVE-2024-26828).
- commit 7164147
- drm/nouveau/debugfs: fix file release memory leak (CVE-2021-47423 bsc#1225366).
- commit 5f7b5c9
- drm/radeon: fix a possible null pointer dereference (CVE-2022-48710 bsc#1225230).
- commit ee59a3e
- nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
(bsc#1225355 CVE-2021-47497).
- commit 30121bc
- drm/vc4: don't check if plane->state->fb == state->fb (CVE-2024-35932 bsc#1224650).
- commit 4fdcf5e
- iio: mma8452: Fix trigger reference couting (bsc#1225360
CVE-2021-47500).
- commit a0d87d5
- PCI/PM: Drain runtime-idle callbacks before driver removal
(CVE-2024-35809 bsc#1224738).
- commit 9f4d35b
- tty: Fix out-of-bound vmalloc access in imageblit
(CVE-2021-47383 bsc#1225208).
- commit a21c750
- ALSA: pcm: oss: Fix negative period/buffer sizes (CVE-2021-47511
bsc#1225411).
- commit 748d8c1
- ALSA: pcm: oss: Limit the period size to 16MB (CVE-2021-47509
bsc#1225409).
- commit 8f92260
- x86/mm/pat: fix VM_PAT handling in COW mappings (bsc#1224525
CVE-2024-35877).
- commit d228bf6
- batman-adv: Avoid infinite loop trying to resize local TT
(CVE-2024-35982 bsc#1224566)
- commit 4f15041
- ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
(CVE-2024-35969 bsc#1224580)
- commit bcaf17a
- kABI workaround for spi_controller (CVE-2021-47469 bsc#1225347).
- commit af00c9b
- spi: Fix deadlock when adding SPI controllers on SPI buses
(CVE-2021-47469 bsc#1225347).
- commit 575a8d4
- kvm: avoid speculation-based attacks from out-of-range memslot
accesses (bsc#1224960, CVE-2021-47277).
- commit 7198007
- KVM: SVM: Flush pages under kvm->lock to fix UAF in
svm_register_enc_region() (bsc#1224725, CVE-2024-35791).
- commit 818a70e
- ipack: ipoctal: fix stack information leak (CVE-2021-47401
bsc#1225242).
- commit 3e8997b
- drm/radeon: possible buffer overflow (CVE-2023-52867 bsc#1225009).
- commit 45094e6
- drm/panel: fix a possible null pointer dereference (CVE-2023-52821 bsc#1225022).
- commit 109e7f1
- RDMA: Verify port when creating flow rule (CVE-2021-47265 bsc#1224957)
- commit c0cbaec
- drm/amd/pm: Update intermediate power state for SI (CVE-2021-47362 bsc#1225153).
- commit 318c627
- mcb: fix error handling in mcb_alloc_bus() (CVE-2021-47361
bsc#1225151).
- commit 813b8ac
- platform/x86: wmi: Fix opening of char device (CVE-2023-52864
bsc#1225132).
- commit b207efb
- pinctrl: single: fix potential NULL dereference (CVE-2022-48708
bsc#1224942).
- commit feac349
- VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
(CVE-2024-35944 bsc#1224648).
- commit a03c425
- net: ipv4: fix memory leak in ip_mc_add1_src
(CVE-2021-47238 bsc#1224847)
- commit 4ce368a
- mmc: sdio: fix possible resource leaks in some error paths
(CVE-2023-52730 bsc#1224956).
- commit 8629def
- atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
(CVE-2021-47355 bsc#1225141).
- commit 111c5b1
- netfilter: synproxy: Fix out of bounds when parsing TCP options
(CVE-2021-47245 bsc#1224838)
- commit 3bf50df
- of: module: prevent NULL pointer dereference in vsnprintf()
(CVE-2024-35878 bsc#1224671).
- commit dcde1a4
- IB/hfi1: Restore allocated resources on failed copyout (CVE-2023-52747 bsc#1224931)
- commit 4ba08d9
- net: rds: fix memory leak in rds_recvmsg
(CVE-2021-47249 bsc#1224880)
- commit 79b2ee2
- sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
(CVE-2021-47397 bsc#1225082)
- commit 2340710
- net: ipv4: fix memory leak in netlbl_cipsov4_add_std
(CVE-2021-47250 bsc#1224827)
- commit ffd876f
- btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
(CVE-2024-35849 bsc#1224733).
- commit 4e18545
- ring-buffer: Fix a race between readers and resize checks
(bsc#1222893).
- commit e55a48c
- ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value
(git-fixes).
- commit 56a4e35
- tracing: hide unused ftrace_event_id_fops (git-fixes).
- commit 6e3bbc9
- tracing: Fix blocked reader of snapshot buffer (git-fixes).
- commit 7cc9ae2
- ALSA: usb-audio: Stop parsing channels bits when all channels
are found (CVE-2024-27436 bsc#1224803).
- ALSA: seq: Fix race of snd_seq_timer_open() (CVE-2021-47281
bsc#1224983).
- commit 19aff08
- af_unix: annote lockless accesses to unix_tot_inflight & gc_in_progress (bsc#1223384).
- commit 8ee0966
- kprobes: Fix possible use-after-free issue on kprobe
registration (git-fixes).
- commit fd63e27
- tracing: Use .flush() call to wake up readers (git-fixes).
- commit 4442cfe
- tracing: Use strncpy instead of memcpy when copying comm in
trace.c (git-fixes).
- commit 77a5fe6
- ring-buffer: Clean ring_buffer_poll_wait() error return
(git-fixes).
- commit dec7c48
- wifi: mac80211: check/clear fast rx for non-4addr sta VLAN
changes (CVE-2024-35789 bsc#1224749).
- media: tc358743: register v4l2 async device only after
successful setup (CVE-2024-35830 bsc#1224680).
- misc/libmasm/module: Fix two use after free in ibmasm_init_one
(CVE-2021-47334 bsc#1225112).
- atm: iphase: fix possible use-after-free in ia_module_exit()
(CVE-2021-47357 bsc#1225144).
- commit 4495db1
- clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
(CVE-2023-52875 bsc#1225096).
- commit eff8019
- clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
(CVE-2023-52865 bsc#1225086).
- commit c2dc4d3
- ax25: fix use-after-free bugs caused by ax25_ds_del_timer
(CVE-2024-35887 bzg#1224663)
- commit 2bbaa4c
- regmap: Fix possible double-free in regcache_rbtree_exit()
(CVE-2021-47483 bsc#1224907).
- commit 1f96a36
- s390/pci: fix max size calculation in zpci_memcpy_toio()
(git-fixes bsc#1225062).
- commit 1d5a845
- s390/zcrypt: fix reference counting on zcrypt card objects
(git-fixes CVE-2024-26957 bsc#1223666).
- commit 1a50d91
- KVM: s390: Check kvm pointer when testing KVM_CAP_S390_HPAGE_1M
(git-fixes bsc#1225059).
- commit b5429fa
- Refresh
patches.suse/USB-core-Fix-deadlock-in-usb_deauthorize_interface.patch.
- Update
patches.suse/bpf-sockmap-Prevent-lock-inversion-deadlock-in-map-d.patch
(bsc#1209657 CVE-2023-0160 CVE-2024-35895 bsc#1224511).
- Update
patches.suse/nfsd-Fix-error-cleanup-path-in-nfsd_rename.patch
(bsc#1221044 CVE-2023-52591 CVE-2024-35914 bsc#1224482).
- Update
patches.suse/wifi-brcmfmac-Fix-use-after-free-bug-in-brcmf_cfg802.patch
(CVE-2023-47233 bsc#1216702 CVE-2024-35811 bsc#1224592).
- commit 9a84305
- Update
patches.suse/powerpc-powernv-Add-a-null-pointer-check-in-opal_eve.patch
(bsc#1065729 CVE-2023-52686 bsc#1224682).
- Update
patches.suse/powerpc-powernv-Add-a-null-pointer-check-in-opal_pow.patch
(bsc#1181674 ltc#189159 git-fixes CVE-2023-52696 bsc#1224601).
- Update
patches.suse/pstore-ram_core-fix-possible-overflow-in-persistent_ram_init_ecc.patch
(git-fixes CVE-2023-52685 bsc#1224728).
- commit 0720a5d
- Update
patches.suse/NFS-Fix-a-potential-NULL-dereference-in-nfs_get_clie.patch
(git-fixes CVE-2021-47260 bsc#1224834).
- Update
patches.suse/PCI-aardvark-Fix-kernel-panic-during-PIO-transfer.patch
(git-fixes CVE-2021-47229 bsc#1224854).
- Update
patches.suse/batman-adv-Avoid-WARN_ON-timing-related-checks.patch
(git-fixes CVE-2021-47252 bsc#1224882).
- Update
patches.suse/can-mcba_usb-fix-memory-leak-in-mcba_usb.patch
(git-fixes CVE-2021-47231 bsc#1224849).
- Update
patches.suse/gfs2-Fix-use-after-free-in-gfs2_glock_shrink_scan.patch
(git-fixes CVE-2021-47254 bsc#1224888).
- Update
patches.suse/media-ngene-Fix-out-of-bounds-bug-in-ngene_command_c.patch
(git-fixes CVE-2021-47288 bsc#1224889).
- Update
patches.suse/memory-fsl_ifc-fix-leak-of-IO-mapping-on-probe-failu.patch
(git-fixes CVE-2021-47315 bsc#1224892).
- Update
patches.suse/memory-fsl_ifc-fix-leak-of-private-memory-on-probe-f.patch
(git-fixes CVE-2021-47314 bsc#1224893).
- Update patches.suse/net-cdc_eem-fix-tx-fixup-skb-leak.patch
(git-fixes CVE-2021-47236 bsc#1224841).
- Update
patches.suse/net-ethernet-fix-potential-use-after-free-in-ec_bhf_.patch
(git-fixes CVE-2021-47235 bsc#1224844).
- Update
patches.suse/net-hamradio-fix-memory-leak-in-mkiss_close.patch
(git-fixes CVE-2021-47237 bsc#1224830).
- Update
patches.suse/net-usb-fix-possible-use-after-free-in-smsc75xx_bind.patch
(bsc#1221994 CVE-2021-47171 CVE-2021-47239 bsc#1224846).
- Update
patches.suse/scsi-core-Fix-error-handling-of-scsi_host_alloc
(git-fixes CVE-2021-47258 bsc#1224899).
- Update
patches.suse/udp-fix-race-between-close-and-udp_abort.patch
(git-fixes CVE-2021-47248 bsc#1224867).
- Update
patches.suse/usb-dwc3-core-fix-kernel-panic-when-do-reboot.patch
(git-fixes CVE-2021-47220 bsc#1224859).
- commit 7295d7f
- Update
patches.suse/gfs2-Fix-use-after-free-in-gfs2_glock_shrink_scan.patch
(git-fixes CVE-2021-47254).
- commit 38ebdb5
- assoc_array: Fix BUG_ON during garbage collect.
- commit 56fe1ad
- list: fix a data-race around ep->rdllist (git-fixes).
- commit f2db318
- lib/mpi: use kcalloc in mpi_resize (git-fixes).
- commit c463c57
- net: usb: ax88179_178a: stop lying about skb->truesize
(git-fixes).
- commit c4bb7b5
- drm/amd/pm: fix a double-free in si_dpm_init (CVE-2023-52691 bsc#1224607).
- commit 7a87ede
- Fix backport of : NFS: Fix error handling for O_DIRECT write
scheduling (bsc#1224785).
- commit e968faa
- rpm/kernel-obs-build.spec.in: remove reiserfs from OBS initrd
We disabled the FS in bug 1202309. And we actively blacklist it in:
/usr/lib/modprobe.d/60-blacklist_fs-reiserfs.conf
This, as a side-effect, fixes obs-build's warning:
dracut-pre-udev[1463]: sh: line 1: /usr/lib/module-init-tools/unblacklist: No such file or directory
Exactly due to the above 60-blacklist_fs-reiserfs.conf trying to call the
above unblacklist.
We should likely drop ext2+ext3 from the list too, as we don't build
them at all. But that's a different story.
- commit 9e1a078
- Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
(bsc#1224174 CVE-2024-27398).
- commit 231873b
- af_unix: Fix garbage collector racing against connect()
(CVE-2024-26923 bsc#1223384).
- af_unix: Replace BUG_ON() with WARN_ON_ONCE() (bsc#1223384).
- af_unix: Do not use atomic ops for unix_sk(sk)->inflight (bsc#1223384).
- commit d9e2f79
- btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl (git-fixes)
- commit db54449
- btrfs: tree-checker: do not error out if extent ref hash doesn't match (git-fixes)
- commit 874e705
- btrfs: send: ensure send_fd is writable (git-fixes)
- commit 7e0fb05
- btrfs: send: limit number of clones and allocated memory size (git-fixes)
- commit fa2504c
- btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP (git-fixes)
- commit 7f9b413
- btrfs: Fix out of bounds access in btrfs_search_slot (git-fixes)
- commit 6b6da17
- btrfs: fix deadlock when writing out space cache (git-fixes)
- commit cdd0586
- btrfs: Explicitly handle btrfs_update_root failure (git-fixes)
- commit ac502aa
- btrfs: undo writable superblocke when sprouting fails (git-fixes)
- commit 9fbf261
- btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit (git-fixes)
- commit daf7dc2
- drm/msm/dpu: Add mutex lock in control vblank irq (CVE-2023-52586 bsc#1221081).
- commit 474c511
- btrfs: prevent to set invalid default subvolid (git-fixes)
- commit c399d80
- Btrfs: fix incorrect {node,sector}size endianness from BTRFS_IOC_FS_INFO (git-fixes)
- commit b016cd3
- Refresh patches.suse/nfs-fix-UAF-in-direct-writes.patch.
Fixup the build warning:
Changed build warnings:
* **** 1 warnings *****
* passing argument 1 of 'nfs_commit_end' from incompatible pointer type [enabled by default] (nfs_commit_end) in ../fs/nfs/direct.c in nfs_direct_commit_complete
../fs/nfs/direct.c: In function 'nfs_direct_commit_complete':
../fs/nfs/direct.c:668:2: warning: passing argument 1 of 'nfs_commit_end' from incompatible pointer type [enabled by default]
- commit 10952b2
- Update
patches.suse/USB-core-Fix-deadlock-in-usb_deauthorize_interface.patch
(git-fixes CVE-2024-26934 bsc#1223671).
- commit cc5c596
- s390/cpum_cf: make crypto counters upward compatible across
machine types (bsc#1224347).
- commit 8af04c2
- scsi: mpt3sas: Fix loop logic (git-fixes).
- scsi: snic: Fix double free in snic_tgt_create() (git-fixes).
- commit d29fa2d
- ecryptfs: fix kernel panic with null dev_name (git-fixes)
- commit 4ecd122
- ecryptfs: Fix typo in message (git-fixes)
- commit b1331d9
- ep_create_wakeup_source(): dentry name can change under you (git-fixes)
- commit e90f9bb
- ecryptfs: fix a memory leak bug in ecryptfs_init_messaging() (git-fixes)
- commit 7163ecf
- ecryptfs: fix a memory leak bug in parse_tag_1_packet() (git-fixes)
- commit d3aeb95
- exportfs_decode_fh(): negative pinned may become positive without the parent locked (git-fixes)
- commit 681e816
- autofs: fix a leak in autofs_expire_indirect() (git-fixes)
- commit 2e9a485
- fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes (git-fixes)
- commit 73af5d9
- fscrypt: clean up some BUG_ON()s in block encryption/decryption (git-fixes)
- commit 2945a7c
- nouveau: lock the client object tree. (bsc#1223834 CVE-2024-27062)
- commit c775ad3
- nouveau: fix instmem race condition around ptr stores (bsc#1223633 CVE-2024-26984)
- commit 9350c2a
- Refresh
patches.suse/x86-boot-Ignore-relocations-in-.notes-sections-in-walk_rel.patch.
- commit 1389ef9
- net: usb: smsc95xx: stop lying about skb->truesize (git-fixes).
- commit 3b70647
- net: usb: sr9700: stop lying about skb->truesize (git-fixes).
- commit d83f5a1
- usb: aqc111: stop lying about skb->truesize (git-fixes).
- commit 0a7bdae
- Fix use-before-set in hand-coded part of patch
Refresh:
- patches.suse/scsi-iscsi_tcp-restrict-to-TCP-sockets.patch.
- commit 757fd5b
- Fix build warning about now-unused function
Refresh:
- patches.suse/scsi-libsas-Fix-disk-not-being-scanned-in-after-being-removed.patch
- commit bbcdd67
- Refresh
patches.suse/media-flexcop-usb-fix-NULL-ptr-deref-in-flexcop_usb_.patch.
Fix the Patch-mainline tag.
- commit 3169adb
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
(git-fixes).
- commit 23ff40d
- usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear
(bsc#1220487 CVE-2021-46933).
- commit 33d6865
- net: gtp: Fix Use-After-Free in gtp_dellink (bsc#1224096
CVE-2024-27396).
- commit a81f04c
- scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()
(git-fixes).
- scsi: lpfc: Correct size for wqe for memset() (git-fixes).
- scsi: libsas: Fix disk not being scanned in after being removed
(git-fixes).
- scsi: libsas: Add a helper sas_get_sas_addr_and_dev_type()
(git-fixes).
- scsi: bfa: Fix function pointer type mismatch for hcb_qe->cbfn
(git-fixes).
- scsi: csiostor: Avoid function pointer casts (git-fixes).
- scsi: isci: Fix an error code problem in isci_io_request_build()
(git-fixes).
- scsi: bnx2fc: Fix skb double free in bnx2fc_rcv() (git-fixes).
- scsi: be2iscsi: Fix a memleak in beiscsi_init_wrb_handle()
(git-fixes).
- scsi: megaraid_sas: Increase register read retry rount from
3 to 30 for selected registers (git-fixes).
- scsi: libfc: Fix potential NULL pointer dereference in
fc_lport_ptp_setup() (git-fixes).
- scsi: mpt3sas: Fix in error path (git-fixes).
- scsi: iscsi_tcp: restrict to TCP sockets (git-fixes).
- scsi: lpfc: Fix the NULL vs IS_ERR() bug for
debugfs_create_file() (git-fixes).
- scsi: mpt3sas: Perform additional retries if doorbell read
returns 0 (git-fixes).
- scsi: qedf: Do not touch __user pointer in
qedf_dbg_fp_int_cmd_read() directly (git-fixes).
- scsi: qedf: Do not touch __user pointer in
qedf_dbg_debug_cmd_read() directly (git-fixes).
- scsi: qedf: Do not touch __user pointer in
qedf_dbg_stop_io_on_error_cmd_read() directly (git-fixes).
- scsi: qla4xxx: Add length check when parsing nlattrs
(git-fixes).
- scsi: be2iscsi: Add length check when parsing nlattrs
(git-fixes).
- scsi: iscsi: Add strlen() check in iscsi_if_set{_host}_param()
(git-fixes).
- scsi: iscsi: Add length check for nlattr payload (git-fixes).
- scsi: qedf: Fix firmware halt over suspend and resume
(git-fixes).
- scsi: qedi: Fix firmware halt over suspend and resume
(git-fixes).
- scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock
(git-fixes).
- scsi: snic: Fix possible memory leak if device_add() fails
(git-fixes).
- scsi: core: Fix possible memory leak if device_add() fails
(git-fixes).
- scsi: core: Fix legacy /proc parsing buffer overflow
(git-fixes).
- scsi: 53c700: Check that command slot is not NULL (git-fixes).
- scsi: 3w-xxxx: Add error handling for initialization failure
in tw_probe() (git-fixes).
- scsi: lpfc: Fix double free in lpfc_cmpl_els_logo_acc() caused
by lpfc_nlp_not_used() (git-fixes).
- scsi: qedf: Fix NULL dereference in error handling (git-fixes).
- scsi: stex: Fix gcc 13 warnings (git-fixes).
- scsi: core: Decrease scsi_device's iorequest_cnt if dispatch
failed (git-fixes).
- commit 43436ef
- Update
patches.suse/net-usb-fix-possible-use-after-free-in-smsc75xx_bind.patch
(bsc#1221994 CVE-2021-47171).
Added bugzilla ID and CVE
The initial fix was present, but it turned later out to be wrong
and the correct fix lacked the references.
- commit cf80be9
- usb: aqc111: check packet for fixup for true limit (bsc#1217169
CVE-2023-52655).
- commit 9dd6dfa
- btrfs: sysfs: use NOFS for device creation (git-fixes)
Adjustment: add #include
- commit f20ad81
- btrfs: send: in case of IO error log it (git-fixes)
- commit 840f907
- btrfs: fix lost error handling when looking up extended ref on log replay (git-fixes)
- commit 20591f1
- btrfs: check if root is readonly while setting security xattr (git-fixes)
- commit 01674b5
- btrfs: limit device extents to the device size (git-fixes)
- commit 0ba992a
- btrfs: fix btrfs_prev_leaf() to not return the same key twice (git-fixes)
- commit 2834caf
- btrfs: fix range_end calculation in extent_write_locked_range (git-fixes)
- commit e723a0b
- btrfs: scrub: reject unsupported scrub flags (git-fixes)
- commit c5866de
- btrfs: fix race when deleting quota root from the dirty cow roots list (git-fixes)
- commit 1e8a661
- btrfs: fix lockdep splat and potential deadlock after failure running delayed items (git-fixes)
- commit 20fccdb
- btrfs: record delayed inode root in transaction (git-fixes)
- commit 7a64f13
- btrfs: tree-checker: fix inline ref size in error messages (git-fixes)
- commit 7031a61
- btrfs: don't stop integrity writeback too early (git-fixes)
- commit 9304b5f
- md: fix kmemleak of rdev->serial (CVE-2024-26900, bsc#1223046).
- commit 0488367
- firewire: nosy: ensure user_length is taken into account when
fetching packet contents (CVE-2024-27401 bsc#1224181).
- commit f890e6b
- aoe: avoid potential deadlock at set_capacity (CVE-2024-26775,
bsc#1222627).
- commit 72683cd
- Update
patches.suse/scsi-ufs-core-Improve-SCSI-abort-handling.patch
(bsc#1222671, CVE-2021-47188).
- commit df1a16c
- nfs: fix UAF in direct writes (bsc#1223653 CVE-2024-26958).
- commit 5347d82
- scsi: libsas: Introduce struct smp_disc_resp (git-fixes).
- commit 5fefdbb
- drm/radeon: add a force flush to delay work when radeon (bsc#1223932 CVE-2022-48704)
- commit 05d207f
- btrfs: don't get an EINTR during drop_snapshot for reloc (git-fixes)
- commit 2f0ddbd
- btrfs: tree-checker: add missing returns after data_ref alignment checks (git-fixes)
- commit 465da04
- btrfs: tree-checker: add missing return after error in root_item (git-fixes)
- commit 2c66867
- btrfs: fix return value mixup in btrfs_get_extent (git-fixes)
- commit c7aefc2
- btrfs: tree-checker: Fix misleading group system information (git-fixes)
- Refresh patches.suse/0014-btrfs-tree-checker-get-fs_info-from-eb-in-block_grou.patch.
- commit 4c1912f
- btrfs: defrag: use btrfs_mod_outstanding_extents in cluster_pages_for_defrag (git-fixes)
- commit 6b856de
- btrfs: fix unaligned access in readdir (git-fixes)
- Refresh patches.suse/btrfs-support-swap-files.patch.
Diff context only.
- commit 0df1b83
- btrfs: Fix NULL pointer exception in find_bio_stripe (git-fixes)
- commit 99eebfb
- net: vmxnet3: Fix NULL pointer dereference in
vmxnet3_rq_rx_complete() (bsc#1223360).
- commit 829bff3
- usb: host: ohci-tmio: check return value after calling
platform_get_resource() (bsc#1222894 CVE-2021-47206).
- blacklist.conf: blacklist entry was a mistake caused by the driver
being dropped upstream, but only after SLE12
- commit 740a25a
- drm/amdgpu: Reset IH OVERFLOW_CLEAR bit (bsc#1223207 CVE-2024-26915)
- commit f1d8ff2
- Update
patches.suse/USB-usb-storage-Prevent-divide-by-0-error-in-isd200_.patch
(bsc#1223738 CVE-2024-27059).
Added CVE and bugzilla ids
- commit 6bf9f21
- usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb
ep transport error (bsc#1223752 CVE-2024-26996).
- commit f8904de
- drm/mediatek: Fix a null pointer crash in (CVE-2024-26874 bsc#1223048)
- commit e57c0ce
- ALSA: emu10k1: Fix out of bounds access in
snd_emu10k1_pcm_channel_alloc() (bsc#1223923 CVE-2022-48702).
- commit af9ea5f
- of: fdt: fix off-by-one error in unflatten_dt_nodes()
(CVE-2022-48672 bsc#1223931).
- commit 032891a
- inet: read sk->sk_family once in inet_recv_error() (bsc#1222385
CVE-2024-26679).
- commit 5c9ee90
- btrfs: abort in rename_exchange if we fail to insert the second ref (CVE-2021-47113 bsc#1221543)
- Refresh patches.suse/btrfs-prevent-rename2-from-exchanging-a-subvol-with-a-directory-from-different-parents.patch.
- commit 6cc4490
- btrfs: dev-replace: properly validate device names (CVE-2024-26791 bsc#1222793)
- commit cc0f00b
- Update
patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
references (CVE-2024-26739 bsc#1222559, drop incorrect references).
- commit ea93ecf
- net/tls: Remove the context from the list in tls_device_down
(bsc#1221545).
- commit 58c1b25
- tls: Fix context leak on tls_device_down (bsc#1221545).
- commit 389808e
- ALSA: usb-audio: Fix an out-of-bounds bug in
__snd_usb_parse_audio_interface() (CVE-2022-48701 bsc#1223921).
- commit 6f798e9
- kabi: hide new member of struct tls_context (CVE-2021-47131
bsc#1221545).
- net/tls: Fix use-after-free after the TLS device goes down
and up (CVE-2021-47131 bsc#1221545).
- commit 8c186be
- Update
patches.suse/SUNRPC-fix-some-memleaks-in-gssx_dec_option_array.patch
(git-fixes CVE-2024-27388 bsc#1223744).
- Update
patches.suse/s390-Once-the-discipline-is-associated-with-the-device-de.patch
(bsc#1141539 git-fixes CVE-2024-27054 bsc#1223819).
- Update
patches.suse/scsi-qla2xxx-Fix-command-flush-on-cable-pull.patch
(bsc1221816 CVE-2024-26931 bsc#1223627).
- Update patches.suse/scsi-qla2xxx-Fix-double-free-of-fcport.patch
(bsc1221816 CVE-2024-26929 bsc#1223715).
- Update
patches.suse/scsi-qla2xxx-Fix-double-free-of-the-ha-vp_map-pointe.patch
(bsc1221816 CVE-2024-26930 bsc#1223626).
- commit daf9a87
- Update
patches.suse/SUNRPC-fix-a-memleak-in-gss_import_v2_context.patch
(git-fixes CVE-2023-52653 bsc#1223712).
- Update patches.suse/aio-fix-mremap-after-fork-null-deref.patch
(git-fixes CVE-2023-52646 bsc#1223432).
- commit 793a07e
- Update
patches.suse/i40e-Fix-kernel-crash-during-module-removal.patch
(git-fixes CVE-2022-48688 bsc#1223953).
- Update
patches.suse/ipv6-sr-fix-out-of-bounds-read-when-setting-HMAC-dat.patch
(bsc#1211592 CVE-2023-2860 CVE-2022-48687 bsc#1223952).
- Update
patches.suse/s390-dasd-fix-Oops-in-dasd_alias_get_start_dev-due-to-missing-pavgroup
(git-fixes CVE-2022-48636 bsc#1223512).
- Update
patches.suse/scsi-mpt3sas-Fix-use-after-free-warning.patch
(git-fixes CVE-2022-48695 bsc#1223941).
- Update
patches.suse/scsi-qla2xxx-Fix-memory-leak-in-__qlt_24xx_handle_ab.patch
(bsc#1203935 CVE-2022-48650 bsc#1223509).
- commit cc68904
- Update
patches.suse/net-dsa-fix-a-crash-if-get_sset_count-fails.patch
(CVE-2021-47146 bsc#1221979 CVE-2021-47159 bsc#1221967).
- Update
patches.suse/scsi-ufs-core-Improve-SCSI-abort-handling.patch
(bsc#11222671 CVE-2021-47188 bsc#1222671).
- commit 5a613f4
- Fix references of
patches.suse/net-dsa-fix-a-crash-if-get_sset_count-fails.patch
This fix actually refers to different CVE and bug report. Fix the error.
- commit b797fc2
- openvswitch: fix stack OOB read while fragmenting IPv4 packets
(CVE-2021-46955 bsc#1220513).
- commit 1116e19
- sctp: fix potential deadlock on &net->sctp.addr_wq_lock
(CVE-2024-0639 bsc#1218917).
- commit de19ab3
- Update
patches.suse/SUNRPC-fix-some-memleaks-in-gssx_dec_option_array.patch
(git-fixes CVE-2024-27388 bsc#1223744).
- Update
patches.suse/s390-Once-the-discipline-is-associated-with-the-device-de.patch
(bsc#1141539 git-fixes CVE-2024-27054 bsc#1223819).
- Update
patches.suse/scsi-qla2xxx-Fix-command-flush-on-cable-pull.patch
(bsc1221816 CVE-2024-26931 bsc#1223627).
- Update patches.suse/scsi-qla2xxx-Fix-double-free-of-fcport.patch
(bsc1221816 CVE-2024-26929 bsc#1223715).
- Update
patches.suse/scsi-qla2xxx-Fix-double-free-of-the-ha-vp_map-pointe.patch
(bsc1221816 CVE-2024-26930 bsc#1223626).
- commit d54495e
- Update
patches.suse/SUNRPC-fix-a-memleak-in-gss_import_v2_context.patch
(git-fixes CVE-2023-52653 bsc#1223712).
- Update patches.suse/aio-fix-mremap-after-fork-null-deref.patch
(git-fixes CVE-2023-52646 bsc#1223432).
- commit 6164312
- Update
patches.suse/s390-dasd-fix-Oops-in-dasd_alias_get_start_dev-due-to-missing-pavgroup
(git-fixes CVE-2022-48636 bsc#1223512).
- Update
patches.suse/scsi-qla2xxx-Fix-memory-leak-in-__qlt_24xx_handle_ab.patch
(bsc#1203935 CVE-2022-48650 bsc#1223509).
- commit b81c322
- drm/tegra: dsi: Add missing check for of_find_device_by_node (CVE-2023-52650 bsc#1223770)
- commit 52453b3
- livepatch: Fix missing newline character in
klp_resolve_symbols() (bsc#1223539).
- commit a04a835
- printk: Update @console_may_schedule in
console_trylock_spinning() (bsc#1223969).
- commit 2217d14
- fs: sysfs: Fix reference leak in sysfs_break_active_protection() (CVE-2024-26993 bsc#1223693)
- commit d5b445d
- drm: nv04: Fix out of bounds access (CVE-2024-27008 bsc#1223802).
- commit d2971e3
- usb: dwc2: Fix memory leak in dwc2_hcd_init.
- commit b68c644
- printk: Disable passing console lock owner completely during
panic() (bsc#1197894).
- commit 7493ac1
- Input: ipaq-micro-keys - add error handling for devm_kmemdup.
- commit 8755dbb
- Input: xpad - add PXN V900 support.
- commit fbd5f3f
- Input: adxl34x - do not hardcode interrupt trigger type
(git-fixes).
- commit 926a03d
- Input: drv260x - sleep between polling GO bit (git-fixes).
- commit e9e8d04
- drm/amd/display: Add a dc_state NULL check in dc_state_release (CVE-2024-26948 bsc#1223664)
- commit 04ae1fa
- USB: core: Fix deadlock in usb_deauthorize_interface().
- commit ab56ab9
- USB: usb-storage: Prevent divide-by-0 error in
isd200_ata_command (git-fixes).
- commit f114b54
- usb: roles: don't get/set_role() when usb_role_switch is
unregistered.
- commit d121124
- usb: mon: Fix atomicity violation in mon_bin_vma_fault
(git-fixes).
- commit 0605a2c
- drivers: usb: host: Fix deadlock in oxu_bus_suspend()
(git-fixes).
- commit 4bfa035
- fuse: don't unhash root (bsc#1223954).
- commit 4838661
- tun: limit printing rate when illegal packet received by tun
dev (bsc#1223745 CVE-2024-27013).
- net/mlx5e: Prevent deadlock while disabling aRFS (bsc#1223735
CVE-2024-27014).
- nfp: flower: handle acti_netdevs allocation failure (bsc#1223827
CVE-2024-27046).
- commit bb18705
- tipc: fix a possible memleak in tipc_buf_append (bsc#1221977
CVE-2021-47162).
- commit 503e448
- media: usbtv: Remove useless locks in usbtv_video_free()
(CVE-2024-27072 bsc#1223837).
- commit 784e536
- media: dvb-frontends: avoid stack overflow warnings with clang
(CVE-2024-27075 bsc#1223842).
- commit 134dc5e
- media: ttpci: fix two memleaks in budget_av_attach
(CVE-2024-27073 bsc#1223843).
- commit 13b28d2
- media: go7007: fix a memleak in go7007_load_encoder
(CVE-2024-27074 bsc#1223844).
- commit 54185dc
- media: edia: dvbdev: fix a use-after-free (CVE-2024-27043
bsc#1223824).
- commit 2732be2
- s390/mm: Fix storage key clearing for guest huge pages
(git-fixes bsc#1223885).
- commit cd536ee
- s390/mm: Fix clearing storage keys for huge pages (git-fixes
bsc#1223883).
- commit a8f7fd9
- media: v4l2-tpg: fix some memleaks in tpg_alloc (CVE-2024-27078
bsc#1223781).
- commit 9ec09ea
- tty/sysrq: replace smp_processor_id() with get_cpu()
(bsc#1223540).
- commit f6b8019
- NTB: fix possible name leak in ntb_register_device()
(CVE-2023-52652 bsc#1223686).
- commit ca5484d
- scsi: ufs: core: Improve SCSI abort handling (bsc#11222671,
CVE-2021-47188).
- blacklist.conf: remove 3ff1f6b
- commit 9ba0cd1
- drm/bridge: adv7511: fix crash on irq during probe (CVE-2024-26876 bsc#1223119).
- commit be1e389
- kABI workaround for cec_adapter (CVE-2024-23848 bsc#1219104).
- media: cec: core: avoid recursive cec_claim_log_addrs
(CVE-2024-23848 bsc#1219104).
- media: cec: core: avoid confusing "transmit timed out" message
(CVE-2024-23848 bsc#1219104).
- media: cec: cec-api: add locking in cec_release()
(CVE-2024-23848 bsc#1219104).
- media: cec: cec-adap: always cancel work in cec_transmit_msg_fh
(CVE-2024-23848 bsc#1219104).
- commit 6debb18
- media: cec: abort if the current transmit was canceled
(CVE-2024-23848 bsc#1219104).
- commit 331f0d4
- cachefiles: fix memory leak in cachefiles_add_cache()
(bsc#1222976 CVE-2024-26840).
- commit 7ab2bde
- net/bnx2x: Prevent access to a freed page in page_pool
(bsc#1223049 CVE-2024-26859).
- commit d2c8d25
- spi: spi-fsl-dspi: Fix a resource leak in an error handling path
(CVE-2021-47161 bsc#1221966).
- commit 86c2723
- amdkfd: use calloc instead of kzalloc to avoid integer overflow (CVE-2024-26817 bsc#1222812)
- commit e67f0f8
- Update
patches.suse/smb3-fix-temporary-data-corruption-in-insert-range.patch
(bsc#1190317 CVE-2022-48667 bsc#1223518).
- commit 91d9162
- Update
patches.suse/smb3-fix-temporary-data-corruption-in-collapse-range.patch
(bsc#1190317 CVE-2022-48668 bsc#1223516).
- commit 10d5c12
- net: fujitsu: fix potential null-ptr-deref (bsc#1221972
CVE-2021-47149).
- commit 9abeb19
- tipc: skb_linearize the head skb when reassembling msgs
(bsc#1221977 CVE-2021-47162).
- commit ba440f6
- net: dsa: fix a crash if ->get_sset_count() fails
(CVE-2021-47146 bsc#1221979).
- commit 599796c
- mld: fix panic in mld_newpack() (CVE-2021-47146 bsc#1221979).
- commit e3d5602
- netfilter: nf_tables: disallow timeout for anonymous sets
(CVE-2023-52620 bsc#1221825).
- commit f690b72
- net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
(CVE-2024-26852 bsc#1223057)
- commit 598df4c
- Update
patches.suse/s390-Once-the-discipline-is-associated-with-the-device-de.patch
(bsc#1141539 git-fixes).
- commit b8b94c0
- quota: Fix potential NULL pointer dereference (bsc#1223060
CVE-2024-26878).
- commit 983d363
- do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
(bsc#1223198 CVE-2024-26901).
- commit 2f53016
- blk-mq: fix IO hang from sbitmap wakeup race (bsc#1222357
CVE-2024-26671).
- commit ecdc50b
- ext4: avoid allocating blocks from corrupted group in
ext4_mb_find_by_goal() (bsc#1222613 CVE-2024-26772).
- commit 3d3003a
- PM / devfreq: Fix buffer overflow in trans_stat_show
(CVE-2023-52614 bsc#1221617).
- commit ad2729f
- net: ice: Fix potential NULL pointer dereference in
ice_bridge_setlink() (bsc#1223051 CVE-2024-26855).
- geneve: make sure to pull inner header in geneve_rx()
(bsc#1223058 CVE-2024-26857).
- ppp_async: limit MRU to 64K (bsc#1222379 CVE-2024-26675).
- ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header
(bsc#1223513 CVE-2022-48651).
- commit bc8fe89
- RDMA/mlx5: Fix fortify source warning while accessing Eth segment (bsc#1223203 CVE-2024-26907)
- commit 1c532b6
- regmap: prevent noinc writes from clobbering cache (bsc#1221162
CVE-2023-52488).
- regmap: fix page selection for noinc writes (bsc#1221162
CVE-2023-52488).
- regmap: fix page selection for noinc reads (bsc#1221162
CVE-2023-52488).
- commit dc5bde0
- usb: dwc2: check return value after calling
platform_get_resource() (git-fixes).
- commit 831627d
- usb: dwc3: gadget: Ignore EP queue requests during bus reset
(git-fixes).
- commit 270950d
- drm/amdgpu: validate the parameters of bo mapping operations more (CVE-2024-26922 bsc#1223315)
- commit 1a7d0fd
- ipvs: Fix checksumming on GSO of SCTP packets (bsc#1221958)
- commit 5e792b9
- i40e: Fix NULL ptr dereference on VSI filter sync (bsc#1222666
CVE-2021-47184).
- commit 1ad3e1d
- usb: gadget: Fix issue with config_ep_by_speed function
(git-fixes).
- commit e3f4200
- x86/boot: Ignore relocations in .notes sections in walk_relocs() too (bsc#1222624 CVE-2024-26816).
- commit b878a00
- x86, relocs: Ignore relocations in .notes section (bsc#1222624 CVE-2024-26816).
- commit d091560
- PM / devfreq: Synchronize devfreq_monitor_[start/stop]
(CVE-2023-52635 bsc#1222294).
- commit faf3604
- Update
patches.suse/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_-2535b848.patch
(bsc#1219170 CVE-2024-22099 CVE-2024-26903 bsc#1223187).
- Update
patches.suse/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch
(bsc#1218562 CVE-2023-6270 CVE-2024-26898 bsc#1223016).
- Update
patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
(CVE-2024-26733 bsc#1222585 CVE-2024-26739 bsc#1222559).
- Update
patches.suse/sr9800-Add-check-for-usbnet_get_endpoints.patch
(git-fixes CVE-2024-26651 bsc#1221337).
- commit f0c3935
- Update
patches.suse/msft-hv-2480-x86-hyperv-Fix-NULL-deref-in-set_hv_tscchange_cb-if-.patch
(git-fixes CVE-2021-47217 bsc#1222836).
- Update
patches.suse/net-dpaa2-eth-fix-use-after-free-in-dpaa2_eth_remove.patch
(git-fixes CVE-2021-47204 bsc#1222787).
- Update patches.suse/scsi-advansys-Fix-kernel-pointer-leak.patch
(git-fixes CVE-2021-47216 bsc#1222876).
- Update
patches.suse/scsi-lpfc-Fix-use-after-free-in-lpfc_unreg_rpi-routi.patch
(bsc#1192145 CVE-2021-47198 bsc#1222883).
- commit 1aa3f8e
- bpf: Fix stackmap overflow check on 32-bit arches (bsc#1223035
CVE-2024-26883).
- bpf: Fix hashtab overflow check on 32-bit arches (bsc#1223189
CVE-2024-26884).
- bpf: Check for integer overflow when using roundup_pow_of_two()
(bsc#1223035 CVE-2024-26883).
- commit 4249641
- IB/hfi1: Fix a memleak in init_credit_return (CVE-2024-26839 bsc#1222975)
- commit 1b9aeec
- Refresh
patches.suse/NFS-add-atomic_open-for-NFSv3-to-handle-O_TRUNC-corr.patch.
Handle too-long file names.
- commit d3b61d6
- wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is
disabled (CVE-2023-52644 bsc#1222961).
- commit 411fc96
- clk: sunxi-ng: Unregister clocks/resets when unbinding
(CVE-2021-47205 bsc#1222888).
- commit 67523b6
- ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
(CVE-2021-47211 bsc#1222869).
- commit a86f817
- Update
patches.suse/scsi-lpfc-Fix-list_add-corruption-in-lpfc_drain_txq.patch
(bsc#1190576 CVE-2021-47203 bsc#1222881).
- commit 2cb2a3c
- ALSA: gus: fix null pointer dereference on pointer block
(CVE-2021-47207 bsc#1222790).
- commit 2c3256c
- wifi: mac80211: fix race condition on enabling fast-xmit
(CVE-2024-26779 bsc#1222772).
- commit 5e02fca
- wifi: rt2x00: restart beacon queue when hardware reset
(CVE-2023-52595 bsc#1221046).
- commit 671852b
- ceph: prevent use-after-free in encode_cap_msg() (bsc#1222503
CVE-2024-26689).
- commit 09813ff
- Update patches.suse/arp-Prevent-overflow-in-arp_req_get.patch
- fix build warning
- commit f10c34a
- kABI: regmap: Add regmap_noinc_read/write API (bsc#1221162
CVE-2023-52488).
- commit fb0c9d2
- regmap: Add regmap_noinc_write API (bsc#1221162 CVE-2023-52488).
- regmap: Add regmap_noinc_read API (bsc#1221162 CVE-2023-52488).
- commit 60efad2
- usb: roles: fix NULL pointer issue when put module's reference
(bsc#1222609 CVE-2024-26747).
- commit 73af327
- serial: sc16is7xx: convert from _raw_ to _noinc_ regmap
functions for FIFO (bsc#1221162 CVE-2023-52488).
- commit a689f3e
- Refresh patches.kabi/cpufeatures-kabi-fix.patch (bsc#1222952)
Don't call set_cpu_caps when calling set_cpu_bug, this causes problems
with overlapping feature/bug ints. Directly call set_bit witht he
correct parameters.
- commit 16e52e8
- md/raid5: fix atomicity violation in raid5_cache_count (bsc#1219169, CVE-2024-23307).
- commit c0dbc35
- ext4: avoid allocating blocks from corrupted group in
ext4_mb_try_best_found() (bsc#1222618 CVE-2024-26773).
- commit 4110538
- thermal: Fix NULL pointer dereferences in of_thermal_ functions (CVE-2021-47202 bsc#1222878)
- commit 08cf92c
- md/raid5: fix atomicity violation in raid5_cache_count
(bsc#1219169, CVE-2024-23307).
- commit 391774d
- fbdev: sis: Error out if pixclock equals zero (bsc#1222765 CVE-2024-26777)
- commit 283e632
- fbdev: savage: Error out if pixclock equals zero (bsc#1222770 CVE-2024-26778)
- commit c2c54cf
- drm: Don't unref the same fb many times by mistake due to deadlock handling (CVE-2023-52486 bsc#1221277).
- commit 5843530
- IB/ipoib: Fix mcast list locking (CVE-2023-52587 bsc#1221082)
- commit 94cde16
- RDMA/IPoIB: Fix error code return in ipoib_mcast_join (bsc#1221082)
- commit 348c98c
- RDMA/srp: Do not call scsi_done() from srp_abort() (CVE-2023-52515 bsc#1221048)
- commit d5d3a97
- RDMA/qedr: Fix qedr_create_user_qp error flow (bsc#1222677 CVE-2024-26743)
- commit c49697b
- RDMA/srpt: Support specifying the srpt_service_guid parameter (bsc#1222449 CVE-2024-26744)
- commit 00d0add
- NFS: avoid spurious warning of lost lock that is being unlocked
(bsc#1221791).
- commit 63a2e3f
- Update
patches.suse/NFS-add-atomic_open-for-NFSv3-to-handle-O_TRUNC-corr.patch
(bsc#1219847 bsc#1221862).
Fix a NULL-pointer-deref bug. Make the patch closer to the patch I sent
upstream.
- commit 5f62723
- dm-crypt: don't modify the data when using authenticated
encryption (bsc#1222720, CVE-2024-26763).
- commit 3e74213
- scsi: core: Fix scsi_mode_sense() buffer length handling
(bsc#1222662 CVE-2021-47182).
- commit 09c6ab5
- dmaengine: ti: edma: Add some null pointer checks to the edma_probe (CVE-2024-26771 bsc#1222610)
- commit 01a7e9c
- netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
(bsc#1222630 CVE-2024-26805).
- commit ad84c88
- Update
patches.suse/gtp-fix-use-after-free-and-null-ptr-deref-in-gtp_gen.patch
(bsc#1222428 CVE-2024-26793 CVE-2024-26754 bsc#1222632).
- commit b4d8fa6
- Update
patches.suse/btrfs-fix-memory-ordering-between-normal-and-ordered-work-functions.patch
(git-fixes CVE-2021-47189 bsc#1222706).
- commit d1ad6f0
- tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
(bsc#1222669 CVE-2021-47185).
- commit 24cc88e
- PCI: pciehp: Add pciehp_set_indicators() to set both indicators
(git-fixes).
- commit deaddb6
- PCI/ASPM: Reduce severity of common clock config message
(git-fixes).
- commit 00c0986
- PCI/ASPM: Don't warn if already in common clock mode
(git-fixes).
- commit 231253b
- PCI/ASPM: Factor out pcie_wait_for_retrain() (git-fixes).
- PCI/ASPM: Return 0 or -ETIMEDOUT from pcie_retrain_link()
(git-fixes).
- PCI: Rework pcie_retrain_link() wait loop (git-fixes).
- commit 4a0cd5a
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 70aa480
- Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch.
Check for bug presence with cpu_has_bug rather than cpu_has so that
overlapping bug/feature bits are handled correctly
- commit ec98c66
- Update
patches.suse/scsi-lpfc-Fix-link-down-processing-to-address-NULL-p.patch
(bsc#1192145 CVE-2021-47183 bsc#1222664).
- commit b599f2b
- Update
patches.suse/usb-musb-tusb6010-check-return-value-after-calling-p.patch
(git-fixes CVE-2021-47181 bsc#1222660).
- commit a0f1eaa
- tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
(bsc#1222619).
- commit 94fc6e9
- PCI: Mark 3ware-9650SE Root Port Extended Tags as broken
(git-fixes).
- PCI/DPC: Print all TLP Prefixes, not just the first (git-fixes).
- PCI/MSI: Prevent MSI hardware interrupt number truncation
(git-fixes).
- PCI/sysfs: Protect driver's D3cold preference from user space
(git-fixes).
- PCI/ASPM: Use RMW accessors for changing LNKCTL (git-fixes).
- PCI: pciehp: Use RMW accessors for changing LNKCTL (git-fixes).
- PCI: Make link retraining use RMW accessors for changing LNKCTL
(git-fixes).
- PCI: Add locking to RMW PCI Express Capability Register
accessors (git-fixes).
- kABI: PCI: Add locking to RMW PCI Express Capability Register
accessors (kabi).
- PCI: qcom: Use DWC helpers for modifying the read-only DBI
registers (git-fixes).
- PCI: qcom: Disable write access to read only registers for IP
v2.3.3 (git-fixes).
- PCI: Add function 1 DMA alias quirk for Marvell 88SE9235
(git-fixes).
- PCI: pciehp: Cancel bringup sequence if card is not present
(git-fixes).
- PCI/ASPM: Avoid link retraining race (git-fixes).
- commit 5d813c6
- arp: Prevent overflow in arp_req_get() (CVE-2024-26733
bsc#1222585).
- commit 64afd8b
- net/sched: act_mirred: don't override retval if we already
lost the skb (CVE-2024-26733 bsc#1222585).
- commit ec837ad
- PCI/ASPM: Disable ASPM on MFD function removal to avoid
use-after-free (git-fixes).
- PCI: pciehp: Fix AB-BA deadlock between reset_lock and
device_lock (git-fixes).
- PCI: switchtec: Return -EFAULT for copy_to_user() errors
(git-fixes).
- PCI: Avoid FLR for AMD FCH AHCI adapters (git-fixes).
- PCI/IOV: Enlarge virtfn sysfs name buffer (git-fixes).
- PCI: hotplug: Allow marking devices as disconnected during
bind/unbind (git-fixes).
- PCI: dwc: Add unroll iATU space support to dw_pcie_disable_atu()
(git-fixes).
- PCI: Add ACS quirk for Broadcom BCM5750x NICs (git-fixes).
- commit 60d94f2
- PCI: endpoint: Don't stop controller when unbinding endpoint
function (git-fixes).
- PCI: qcom: Fix unbalanced PHY init on probe errors (git-fixes).
- PCI: Avoid pci_dev_lock() AB/BA deadlock with
sriov_numvfs_store() (git-fixes).
- PCI/PM: Power up all devices during runtime resume (git-fixes).
- PCI/AER: Clear MULTI_ERR_COR/UNCOR_RCV bits (git-fixes).
- PCI: aardvark: Fix setting MSI address (git-fixes).
- PCI: aardvark: Fix support for MSI interrupts (git-fixes).
- commit fd2813d
- Refresh
patches.suse/Bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch.
Add alternate ID for stable
- commit 38c4e25
- Bluetooth: btqcomsmd: Fix command timeout after setting BD
address (git-fixes).
- commit de57587
- Bluetooth: hci_intel: Add check for platform_driver_register
(git-fixes).
- commit 0e58b3a
- Bluetooth: btqca: Introduce HCI_EV_VENDOR and use it
(git-fixes).
- commit 7e74176
- Bluetooth: btqca: Fixed a coding style error (git-fixes).
- commit 0f83a52
- ext4: fix double-free of blocks due to wrong extents moved_len
(bsc#1222422 CVE-2024-26704).
- commit da029ac
- Refresh
patches.suse/bpf-sockmap-Prevent-lock-inversion-deadlock-in-map-d.patch.
- commit 6490813
- gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
(bsc#1222428 CVE-2024-26793).
- gtp: fix use-after-free and null-ptr-deref in
gtp_genl_dump_pdp() (bsc#1222428 CVE-2024-26793).
- commit 9c6b7d6
- nfsd: Fix error cleanup path in nfsd_rename() (bsc#1221044
CVE-2023-52591).
- commit b8b869c
- usb: musb: Modify the "HWVers" register address (git-fixes).
- commit d99cd58
- sr9800: Add check for usbnet_get_endpoints (git-fixes).
- commit 24ceaa4
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
Fix aliasing problems if we have an extended capability which aliases a
non-extended bug bit. The fix is to always ensure that bug bits related
functionality doesn't use the "generic" cap functionality.
- commit c674af2
- Update
patches.suse/KVM-s390-vsie-fix-race-during-shadow-creation.patch
(git-fixes bsc#1220613 CVE-2023-52639 bsc#1222300).
- Update
patches.suse/netfilter-nftables-exthdr-fix-4-byte-stack-OOB-write.patch
(CVE-2023-4881 bsc#1215221 CVE-2023-52628 bsc#1222117).
- commit 5564fa1
- nfsd: Fix error cleanup path in nfsd_rename() (git-fixes).
- commit c8d258d
- x86/bhi: Mitigate KVM by default (bsc#1217339 CVE-2024-2201).
- commit 7079142
- x86/bhi: Add BHI mitigation knob (bsc#1217339 CVE-2024-2201).
- Update config files.
- commit 41d6371
- x86/bhi: Enumerate Branch History Injection (BHI) bug (bsc#1217339 CVE-2024-2201).
- commit 2432a6f
- x86/bhi: Define SPEC_CTRL_BHI_DIS_S (bsc#1217339 CVE-2024-2201).
- commit fe53768
- x86/bhi: Add support for clearing branch history at syscall entry (bsc#1217339 CVE-2024-2201).
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 955ab56
- Fixup NULL ptr dereference due to mistake in backporting in
patches.suse/ext2-Avoid-reading-renamed-directory-if-parent-does-.patch.
- commit 55001e0
- Delete
patches.suse/x86-bugs-Fix-the-SRSO-mitigation-on-Zen3-4.patch.
the kernel fails to boot on x86:
[ 0.048461] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.048698] MMIO Stale Data: Unknown: No mitigations
qemu-system-x86_64: terminating on signal 15 from pid 42034 (timeout)
- commit 035c88f
- x86/cpufeature: Add missing leaf enumeration (bsc#1217339 CVE-2024-2201).
- commit 248bb60
- Update references
- commit 1bab65d
- scsi: lpfc: Fix a possible data race in
lpfc_unregister_fcf_rescan() (bsc#1219618 CVE-2024-24855).
- commit 6004b44
- media: xc4000: Fix atomicity violation in xc4000_get_frequency
(git-fixes bsc#1219623 CVE-2024-24861).
- commit ad0b314
- x86/bugs: Fix the SRSO mitigation on Zen3/4 (git-fixes).
- commit 8032e89
- bpf, sockmap: Prevent lock inversion deadlock in map delete elem
(bsc#1209657 CVE-2023-0160).
- commit 40497a8
- bpf, sockmap: Fix preempt_rt splat when using raw_spin_lock_t
(git-fixes).
- commit 3c6384f
- bnx2x: Fix enabling network interfaces without VFs (git-fixes).
- commit b60bea3
- ethernet: myri10ge: Fix missing error code in myri10ge_probe()
(git-fixes).
- commit 71a7d56
- bnx2x: Fix missing error code in bnx2x_iov_init_one()
(git-fixes).
- commit 813cb9c
- net: macb: ensure the device is available before accessing
GEMGXL control registers (git-fixes).
- commit 1742349
- net/qla3xxx: fix schedule while atomic in ql_sem_spinlock
(git-fixes).
- commit 8e475cb
- netfilter: nf_tables: disallow anonymous set with timeout flag
(CVE-2024-26642 bsc#1221830).
- commit b3d18fd
- netfilter: ctnetlink: fix possible refcount leak in
ctnetlink_create_conntrack() (CVE-2023-7192 bsc#1218479).
- commit 0774a95
- net: allwinner: Fix some resources leak in the error handling path of the probe and in the remove function (git-fixes).
- commit d464181
- ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram (git-fixes).
- commit 6895e10
- net/mlx5: Properly convey driver version to firmware (git-fixes).
- commit 09bc4c8
- net: stmmac: free tx skb buffer in stmmac_resume() (git-fixes).
- commit 7769206
- tun: honor IOCB_NOWAIT flag (git-fixes).
- commit 1f0149b
- atl1e: fix error return code in atl1e_probe() (git-fixes).
- commit da6dd80
- atl1c: fix error return code in atl1c_probe() (git-fixes).
- commit 56e0459
- net: atheros: switch from 'pci_' to 'dma_' API (git-fixes).
- commit 47ce14b
- README.BRANCH: Remove copy of branch name
- commit 26f4895
- usb: dwc3: core: Do not perform GCTL_CORE_SOFTRESET during
bootup (bsc#1220628 CVE-2021-46941).
- commit ebce255
- usb: dwc3: core: balance phy init and exit (bsc#1220628
CVE-2021-46941).
- commit 8f693d2
- USB: usbfs: Don't WARN about excessively large memory
allocations.
- commit 8172f18
- ipv6: init the accept_queue's spinlocks in inet6_create
(bsc#1221293 CVE-2024-26614).
- commit 6bea6a5
- tcp: make sure init the accept_queue's spinlocks once
(bsc#1221293 CVE-2024-26614).
- commit 800aa0a
- userfaultfd: release page in error path to avoid BUG_ON
(CVE-2021-46988 bsc#1220706).
- commit bcafeec
- powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
(CVE-2023-52607 bsc#1221061).
- commit af6f33a
- Update
patches.suse/net-nfc-llcp-Add-lock-when-modifying-device-list.patch
(git-fixes CVE-2023-52524 bsc#1220927).
- Update
patches.suse/net-usb-smsc75xx-Fix-uninit-value-access-in-__smsc75.patch
(git-fixes CVE-2023-52528 bsc#1220843).
- Update
patches.suse/nvmet-tcp-Fix-a-kernel-panic-when-host-sends-an-inva.patch
(bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
CVE-2023-6356 CVE-2023-52454 bsc#1220320).
- Update
patches.suse/ocfs2-Avoid-touching-renamed-directory-if-parent-doe.patch
(bsc#1221044 CVE-2023-52591 CVE-2023-52590 bsc#1221088).
- Update
patches.suse/ravb-Fix-use-after-free-issue-in-ravb_tx_timeout_wor.patch
(bsc#1212514 CVE-2023-35827 CVE-2023-52509 bsc#1220836).
- Update
patches.suse/x86-srso-fix-sbpb-enablement-for-spec_rstack_overflow-off.patch
(git-fixes CVE-2023-52575 bsc#1220871).
- commit 2258ead
- Update patches.suse/mmc-moxart_remove-Fix-UAF.patch (bsc#1194516
CVE-2022-0487 CVE-2022-48626 bsc#1220366).
- commit 10fc152
- Update
patches.suse/0019-dm-rq-fix-double-free-of-blk_mq_tag_set-in-dev-remov.patch
(git fixes CVE-2021-46938 bsc#1220554).
- Update
patches.suse/ACPI-custom_method-fix-potential-use-after-free-issu.patch
(git-fixes CVE-2021-46966 bsc#1220572).
- Update
patches.suse/ARM-footbridge-fix-PCI-interrupt-mapping.patch
(git-fixes CVE-2021-46909 bsc#1220442).
- Update
patches.suse/IB-qib-Fix-memory-leak-in-qib_user_sdma_queue_pkts.patch
(git-fixes CVE-2021-47104 bsc#1220960).
- Update
patches.suse/NFC-nci-fix-memory-leak-in-nci_allocate_device.patch
(git-fixes CVE-2021-47180 bsc#1221999).
- Update
patches.suse/NFS-Don-t-corrupt-the-value-of-pg_bytes_written-in-n.patch
(git-fixes CVE-2021-47166 bsc#1221998).
- Update
patches.suse/NFS-Fix-an-Oopsable-condition-in-__nfs_pageio_add_re.patch
(git-fixes CVE-2021-47167 bsc#1221991).
- Update
patches.suse/NFS-fix-an-incorrect-limit-in-filelayout_decode_layo.patch
(git-fixes CVE-2021-47168 bsc#1222002).
- Update
patches.suse/NFSv4-Fix-a-NULL-pointer-dereference-in-pnfs_mark_ma.patch
(git-fixes CVE-2021-47179 bsc#1222001).
- Update
patches.suse/asix-fix-uninit-value-in-asix_mdio_read.patch
(git-fixes CVE-2021-47101 bsc#1220987).
- Update
patches.suse/bnxt_en-Fix-RX-consumer-index-logic-in-the-error-pat.patch
(git-fixes CVE-2021-47015 bsc#1220794).
- Update
patches.suse/btrfs-fix-race-between-transaction-aborts-and-fsyncs.patch
(bsc#1186441 CVE-2021-46958 bsc#1220521).
- Update
patches.suse/cifs-Return-correct-error-code-from-smb2_get_enc_key.patch
(git-fixes CVE-2021-46960 bsc#1220528).
- Update
patches.suse/crypto-qat-ADF_STATUS_PF_RUNNING-should-be-set-after.patch
(git-fixes CVE-2021-47056 bsc#1220769).
- Update
patches.suse/cxgb4-avoid-accessing-registers-when-clearing-filter.patch
(bsc#1136345 jsc#SLE-4681 CVE-2021-47138 bsc#1221934).
- Update patches.suse/drm-amdgpu-Fix-a-use-after-free.patch
(git-fixes CVE-2021-47142 bsc#1221952).
- Update
patches.suse/drm-meson-fix-shutdown-crash-when-component-not-prob.patch
(git-fixes CVE-2021-47165 bsc#1221965).
- Update
patches.suse/ethernet-enic-Fix-a-use-after-free-bug-in-enic_hard_.patch
(bsc#1113431 CVE-2021-46998 bsc#1220625).
- Update
patches.suse/ext4-fix-bug-on-in-ext4_es_cache_extent-as-ext4_spli.patch
(bsc#1187408 CVE-2021-47117 bsc#1221575).
- Update
patches.suse/ext4-fix-memory-leak-in-ext4_fill_super.patch
(bsc#1187409 CVE-2021-47119 bsc#1221608).
- Update
patches.suse/gve-Add-NULL-pointer-checks-when-freeing-irqs.patch
(bsc#1176940 CVE-2021-47141 bsc#1221949).
- Update
patches.suse/i2c-i801-Don-t-generate-an-interrupt-on-bus-reset.patch
(git-fixes CVE-2021-47153 bsc#1221969).
- Update patches.suse/iommu-vt-d-fix-sysfs-leak-in-alloc_iommu
(bsc#1189272 CVE-2021-47177 bsc#1221997).
- Update
patches.suse/ipmi-Fix-UAF-when-uninstall-ipmi_si-and-ipmi_msghand.patch
(git-fixes CVE-2021-47100 bsc#1220985).
- Update
patches.suse/kvm-destroy-i-o-bus-devices-on-unregister-failure-after_-sync-ing-srcu
(CVE-2020-36312 bsc#1184509 CVE-2021-47061 bsc#1220745).
- Update
patches.suse/kvm-stop-looking-for-coalesced-mmio-zones-if-the-bus-is-destroyed
(CVE-2020-36312 bsc#1184509 CVE-2021-47060 bsc#1220742).
- Update
patches.suse/md-raid1-properly-indicate-failure-when-ending-a-fai.patch
(bsc#1185680 CVE-2021-46950 bsc#1220662).
- Update
patches.suse/misc-uss720-fix-memory-leak-in-uss720_probe.patch
(git-fixes CVE-2021-47173 bsc#1221993).
- Update
patches.suse/msft-hv-2305-Drivers-hv-vmbus-Use-after-free-in-__vmbus_open.patch
(git-fixes CVE-2021-47049 bsc#1220692).
- Update
patches.suse/msft-hv-2316-uio_hv_generic-Fix-a-memory-leak-in-error-handling-p.patch
(git-fixes CVE-2021-47071 bsc#1220846).
- Update
patches.suse/msft-hv-2317-uio_hv_generic-Fix-another-memory-leak-in-error-hand.patch
(git-fixes CVE-2021-47070 bsc#1220829).
- Update
patches.suse/mtd-require-write-permissions-for-locking-and-badblo.patch
(git-fixes CVE-2021-47055 bsc#1220768).
- Update
patches.suse/nbd-Fix-NULL-pointer-in-flush_workqueue-79eb.patch
(git-fixes CVE-2021-46981 bsc#1220611).
- Update
patches.suse/net-fec-fix-the-potential-memory-leak-in-fec_enet_in.patch
(git-fixes CVE-2021-47150 bsc#1221973).
- Update
patches.suse/net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch
(CVE-2021-23134 bsc#1186060 CVE-2021-47068 bsc#1220739).
- Update
patches.suse/net-smc-remove-device-from-smcd_dev_list-after-failed-device_add
(git-fixes CVE-2021-47143 bsc#1221988).
- Update
patches.suse/net-usb-fix-memory-leak-in-smsc75xx_bind.patch
(git-fixes CVE-2021-47171 bsc#1221994).
- Update patches.suse/ocfs2-fix-data-corruption-by-fallocate.patch
(bsc#1187412 CVE-2021-47114 bsc#1221548).
- Update
patches.suse/pid-take-a-reference-when-initializing-cad_pid.patch
(bsc#1114648 CVE-2021-47118 bsc#1221605).
- Update
patches.suse/platform-x86-dell-smbios-wmi-Fix-oops-on-rmmod-dell_.patch
(git-fixes CVE-2021-47073 bsc#1220850).
- Update
patches.suse/powerpc-64s-Fix-crashes-when-toggling-entry-flush-ba.patch
(bsc#1177666 git-fixes bsc#1186460 ltc#192531 CVE-2021-46990
bsc#1220743).
- Update
patches.suse/powerpc-64s-Fix-pte-update-for-kernel-memory-on-radi.patch
(bsc#1055117 git-fixes CVE-2021-47034 bsc#1220687).
- Update
patches.suse/scsi-lpfc-Fix-null-pointer-dereference-in-lpfc_prep_.patch
(bsc#1182574 CVE-2021-47045 bsc#1220640).
- Update
patches.suse/scsi-qla2xxx-Fix-crash-in-qla2xxx_mqueuecommand.patch
(bsc#1185491 CVE-2021-46963 bsc#1220536).
- Update patches.suse/scsi-qla2xxx-Reserve-extra-IRQ-vectors.patch
(bsc#1185491 CVE-2021-46964 bsc#1220538).
- Update
patches.suse/serial-rp2-use-request_firmware-instead-of-request_f.patch
(git-fixes CVE-2021-47169 bsc#1222000).
- Update
patches.suse/tracing-Restructure-trace_clock_global-to-never-block.patch
(git-fixes CVE-2021-46939 bsc#1220580).
- Update
patches.suse/vsock-virtio-free-queued-packets-when-closing-socket.patch
(git-fixes CVE-2021-47024 bsc#1220637).
- Update
patches.suse/x86-kvm-Disable-kvmclock-on-all-CPUs-on-shutdown.patch
(bsc#1185308 CVE-2021-47110 bsc#1221532).
- Update
patches.suse/x86-kvm-Teardown-PV-features-on-boot-CPU-as-well.patch
(bsc#1185308 CVE-2021-47112 bsc#1221541).
- commit fa763cd
- Update
patches.suse/netlabel-fix-out-of-bounds-memory-accesses.patch
(networking-stable-19_03_07 CVE-2019-25160 bsc#1220394).
- commit cfd1daa
- IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests (bsc#1220445 CVE-2023-52474)
- commit 71ecb14
- s390/vtime: fix average steal time calculation (git-fixes
bsc#1221953).
- commit ccf7a1f
- s390/ptrace: handle setting of fpc register correctly
(CVE-2023-52598 bsc#1221060 git-fixes).
- commit 0d179a3
- wifi: ath10k: fix NULL pointer dereference in
ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() (bsc#1218336
CVE-2023-7042).
- commit 1463c4a
- x86/CPU/AMD: Update the Zenbleed microcode revisions (git-fixes).
- commit 11a703b
- kabi fix for pNFS: Fix the pnfs block driver's calculation of
layoutget size (git-fixes).
- commit 188e451
- pNFS: Fix the pnfs block driver's calculation of layoutget size
(git-fixes).
- NFS: Fix O_DIRECT locking issues (git-fixes).
- NFS: Fix direct WRITE throughput regression (git-fixes).
- commit 53dafcd
- NFS: Fix an off by one in root_nfs_cat() (git-fixes).
- net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr()
(git-fixes).
- SUNRPC: fix a memleak in gss_import_v2_context (git-fixes).
- NFS: More O_DIRECT accounting fixes for error paths (git-fixes).
- NFS: Fix error handling for O_DIRECT write scheduling
(git-fixes).
- nfs: only issue commit in DIO codepath if we have uncommitted
data (git-fixes).
- NFS: Fix a request reference leak in
nfs_direct_write_clear_reqs() (git-fixes).
- NFS: Fix O_DIRECT commit verifier handling (git-fixes).
- NFS: commit errors should be fatal (git-fixes).
- commit c3fe0ca
- Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
(bsc#1219170 CVE-2024-22099).
- commit f6c10f5
- scsi: qla2xxx: Update version to 10.02.09.200-k (bsc1221816).
- scsi: qla2xxx: Delay I/O Abort on PCI error (bsc1221816).
- scsi: qla2xxx: Change debug message during driver unload
(bsc1221816).
- scsi: qla2xxx: Fix double free of fcport (bsc1221816).
- scsi: qla2xxx: Fix double free of the ha->vp_map pointer
(bsc1221816).
- scsi: qla2xxx: Fix command flush on cable pull (bsc1221816).
- scsi: qla2xxx: NVME|FCP prefer flag not being honored
(bsc1221816).
- scsi: qla2xxx: Update manufacturer detail (bsc1221816).
- scsi: qla2xxx: Split FCE|EFT trace control (bsc1221816).
- scsi: qla2xxx: Fix N2N stuck connection (bsc1221816).
- scsi: qla2xxx: Prevent command send on chip reset (bsc1221816).
- commit 61951e8
- drm: bridge/panel: Cleanup connector on bridge detach (bsc#1220777, CVE-2021-47063)
Backporting changes:
- add patch at the top of panel_bridge_detach()
- commit 760a99d
- aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
(bsc#1218562 CVE-2023-6270).
- commit 4e659c8
- net: Fix features skip in for_each_netdev_feature() (git-fixes).
- commit b1996ba
- rename(): avoid a deadlock in the case of parents having no
common ancestor (bsc#1221044 CVE-2023-52591).
- commit 16f9b33
- kill lock_two_inodes() (bsc#1221044 CVE-2023-52591).
- commit c8410b2
- rename(): fix the locking of subdirectories (bsc#1221044
CVE-2023-52591).
- commit b34d065
- f2fs: Avoid reading renamed directory if parent does not change
(bsc#1221044 CVE-2023-52591).
- commit 95ecb76
- ext4: don't access the source subdirectory content on
same-directory rename (bsc#1221044 CVE-2023-52591).
- commit e81c5d2
- ext2: Avoid reading renamed directory if parent does not change
(bsc#1221044 CVE-2023-52591).
- commit 47af51c
- udf_rename(): only access the child content on cross-directory
rename (bsc#1221044 CVE-2023-52591).
- commit 3e77e59
- ocfs2: Avoid touching renamed directory if parent does not
change (bsc#1221044 CVE-2023-52591).
- commit ef44829
- reiserfs: Avoid touching renamed directory if parent does not
change (git-fixes bsc#1221044 CVE-2023-52591).
Refresh patches.suse/reiserfs-add-check-to-detect-corrupted-directory-entry.patch
Refresh patches.suse/reiserfs-don-t-panic-on-bad-directory-entries.patch
- commit 304c6b9
- fs: don't assume arguments are non-NULL (bsc#1221044
CVE-2023-52591).
- commit 74a158f
- fs: Restrict lock_two_nondirectories() to non-directory inodes
(bsc#1221044 CVE-2023-52591).
- commit 2042147
- fs: ocfs2: check status values (bsc#1221044 CVE-2023-52591).
- commit 24568a1
- fs: no need to check source (bsc#1221044 CVE-2023-52591).
- commit 95711fd
- fs: Lock moved directories (bsc#1221044 CVE-2023-52591).
- commit 2b2136e
- fs: Establish locking order for unrelated directories
(bsc#1221044 CVE-2023-52591).
- commit c49cfde
- fs: introduce lock_rename_child() helper (bsc#1221044
CVE-2023-52591).
- commit 84b4b7d
- dwc3: switch to a global mutex (bsc#1220628 CVE-2021-46941).
- commit d93342d
- usb: dwc3: core: Do core softreset when switch mode (bsc#1220628
CVE-2021-46941).
- blacklist.conf: needed after all for a CVE
- Refresh
patches.suse/USB-dwc3-fix-runtime-pm-imbalance-on-probe-errors.patch.
- Refresh
patches.suse/usb-dwc3-Fix-race-between-dwc3_set_mode-and-__dwc3_s.patch.
- commit 7ca4d31
- Input: add bounds checking to input_set_capability()
(bsc#1218220 CVE-2022-48619).
- commit f42351b
- NFSD: Retransmit callbacks after client reconnects (git-fixes).
- NFSD: Reset cb_seq_status after NFS4ERR_DELAY (git-fixes).
- SUNRPC: fix some memleaks in gssx_dec_option_array (git-fixes).
- NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICT
(git-fixes).
- SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
(git-fixes).
- nfsd: lock_rename() needs both directories to live on the same
fs (git-fixes).
- pNFS/flexfiles: Check the layout validity in
ff_layout_mirror_prepare_stats (git-fixes).
- commit 311216b
- perf/x86/lbr: Filter vsyscall addresses (bsc#1220703,
CVE-2023-52476).
- commit ff86f16
- net/sched: Remove alias of sch_clsact (bsc#1210335 CVE-2023-1829).
- net/sched: Load modules via their alias (bsc#1210335 CVE-2023-1829).
- net/sched: Add module aliases for cls_,sch_,act_ modules
(bsc#1210335 CVE-2023-1829).
- net/sched: Add helper macros with module names (bsc#1210335 CVE-2023-1829).
- commit 609fe5f
- x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set (bsc#1213456 CVE-2023-28746).
- commit c5b2dec
- Sort patches that are already upstream
- Refresh
patches.suse/Documentation-hw-vuln-Add-documentation-for-RFDS.patch.
- Refresh
patches.suse/KVM-x86-Export-RFDS_NO-and-RFDS_CLEAR-to-guests.patch.
- Refresh
patches.suse/x86-rfds-Mitigate-Register-File-Data-Sampling-RFDS.patch.
- commit 031146a
- iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
(git-fixes).
- commit ea9ae09
- iommu: Check if group is NULL before remove device (git-fixes).
- commit a7b6fa2
- iommu/amd: Silence warnings under memory pressure (git-fixes).
- commit cdec216
- iommu/amd: Increase interrupt remapping table limit to 512
entries (git-fixes).
- commit c290a72
- iommu/amd: Mark interrupt as managed (git-fixes).
- commit 34b8fef
- ARM: 9064/1: hw_breakpoint: Do not directly check the event's
overflow_handler hook (bsc#1220751 CVE-2021-47006).
- commit 605e3a7
- Refresh patches.kabi/team-Hide-new-member-header-ops.patch.
Fix for kABI workaround.
- commit f1bcdf5
- usb: typec: class: fix typec_altmode_put_partner to put plugs
(git-fixes).
- commit 4350c0c
- ceph: fix deadlock or deadcode of misusing dget() (bsc#1221058
CVE-2023-52583).
- commit a413cb6
- usb: hub: Guard against accesses to uninitialized BOS
descriptors (bsc#1220790 CVE-2023-52477).
- commit bf5af19
- Refresh patches.kabi/cpufeatures-kabi-fix.patch. (bsc#1221287)
X86_FEATURE_LFENCE_RDTSC became an extended bit and was set via
cpu_set_cap as opposed to setup_force_cpu_cap. So extend the
infrastructure to also cover cpu_set_cap.
- commit 3fcb500
- net: lan78xx: fix runtime PM count underflow on link stop
(git-fixes).
- commit 7281e3e
- lan78xx: Fix race conditions in suspend/resume handling
(git-fixes).
- commit 91c55e5
- lan78xx: Fix partial packet errors on suspend/resume
(git-fixes).
- commit 99adbef
- lan78xx: Add missing return code checks (git-fixes).
- Refresh
patches.suse/bsc1084332-0003-lan78xx-Enable-LEDs-and-auto-negotiation.patch.
- Refresh
patches.suse/lan78xx-Fix-exception-on-link-speed-change.patch.
- commit 5704b69
- lan78xx: Fix exception on link speed change (git-fixes).
- commit dbfd125
- lan78xx: Fix white space and style issues (git-fixes).
- commit eb3a9cf
- net: usb: lan78xx: Remove lots of set but unused 'ret' variables
(git-fixes).
- commit 378d7a7
- net: lan78xx: remove set but not used variable 'event'
(git-fixes).
- commit b7f01b9
- net: lan78xx: Merge memcpy + lexx_to_cpus to get_unaligned_lexx
(git-fixes).
- lan78xx: Do not access skb_queue_head list pointers directly
(git-fixes).
- commit f2cbfb9
- net: lan78xx: Make declaration style consistent (git-fixes).
- commit be1816d
- net:usb: Use ARRAY_SIZE instead of calculating the array size
(git-fixes).
- commit 360121f
- net: lan78xx: Allow for VLAN headers in timeout calcs
(git-fixes).
- commit d43b68c
- lan78xx: Modify error messages (git-fixes).
- commit afd21b5
- lan78xx: Add support to dump lan78xx registers (git-fixes).
- commit c4b2e78
- lan78xx: enable auto speed configuration for LAN7850 if no
EEPROM is detected (git-fixes).
- commit 3edfed0
- drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() (bsc#1220413 CVE-2023-52470).
- commit f1a2e90
- drivers/amd/pm: fix a use-after-free in kv_parse_power_table (bsc#1220411 CVE-2023-52469).
- commit 3357315
- group-source-files.pl: Quote filenames (boo#1221077).
The kernel source now contains a file with a space in the name.
Add quotes in group-source-files.pl to avoid splitting the filename.
Also use -print0 / -0 when updating timestamps.
- commit a005e42
- Update
patches.suse/net-hso-fix-NULL-deref-on-disconnect-regression.patch
(bsc#1220416 bsc#1220418 CVE-2021-46905 CVE-2021-46904).
Added second CVE reference
- commit f72c3a5
- gve: Fix skb truesize underestimation (git-fixes).
- commit 983edc4
- Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"
(git-fixes).
- commit 3ea2575
- phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP (bsc#1220340,CVE-2024-26600)
- commit 20e2c08
- RDMA/rxe: Clear all QP fields if creation failed (bsc#1220863 CVE-2021-47078)
- commit f8dcd39
- RDMA/rxe: Return CQE error if invalid lkey was supplied (bsc#1220860 CVE-2021-47076)
- commit 3f60a4e
- ACPI: extlog: fix NULL pointer dereference check (bsc#1221039
CVE-2023-52605).
- commit b0968bd
- KVM: s390: fix setting of fpc register (bsc#1221040
CVE-2023-52597).
- commit 0f89ca1
- net: hso: fix NULL-deref on disconnect regression (bsc#1220416
CVE-2021-46904).
- commit fe1eee0
- net: hso: fix null-ptr-deref during tty device unregistration
(bsc#1220416 CVE-2021-46904).
- commit d61504e
- kernel-binary: Fix i386 build
Fixes: 89eaf4cdce05 ("rpm templates: Move macro definitions below buildrequires")
- commit f7c6351
- net: usb: dm9601: fix wrong return value in dm9601_mdio_read
(git-fixes).
- commit d69a5b8
- net: nfc: llcp: Add lock when modifying device list (git-fixes).
- commit b462198
- igb: clean up in all error paths when enabling SR-IOV
(git-fixes).
- commit 0f0e6a7
- net/sched: tcindex: search key must be 16 bits (git-fixes).
- commit 190e0f5
- stmmac: fix potential division by 0 (git-fixes).
- commit 40876e6
- kcm: fix strp_init() order and cleanup (git-fixes).
- commit b31a598
- ipv6: fix typos in __ip6_finish_output() (git-fixes).
- commit 54553b6
- kabi: team: Hide new member header_ops (bsc#1220870
CVE-2023-52574).
- commit 9fab77a
- wcn36xx: fix RX BD rate mapping for 5GHz legacy rates
(git-fixes).
- commit c4e8a82
- wcn36xx: Fix discarded frames due to wrong sequence number
(git-fixes).
- commit 8553436
- x86/srso: Add SRSO mitigation for Hygon processors (bsc#1220735
CVE-2023-52482).
- commit c7d3dd8
- Revert "wcn36xx: Disable bmps when encryption is disabled"
(git-fixes).
- commit e5924b8
- vt: fix memory overlapping when deleting chars in the buffer
(bsc#1220845 CVE-2022-48627).
- commit 6d7d615
- wcn36xx: Fix (QoS) null data frame bitrate/modulation
(git-fixes).
- commit 405ced7
- ipv6: Fix handling of LLA with VRF and sockets bound to VRF
(git-fixes).
- commit 519a8b2
- kcm: Call strp_stop before strp_done in kcm_attach (git-fixes).
- commit b01e9bb
- kernel-binary: vdso: fix filelist for non-usrmerged kernel
Fixes: a6ad8af207e6 ("rpm templates: Always define usrmerged")
- commit fb3f221
- KVM: x86: Export RFDS_NO and RFDS_CLEAR to guests (bsc#1213456 CVE-2023-28746).
- commit 789616b
- x86/rfds: Mitigate Register File Data Sampling (RFDS) (bsc#1213456 CVE-2023-28746).
- Update config files.
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 47b68f4
- Documentation/hw-vuln: Add documentation for RFDS (bsc#1213456 CVE-2023-28746).
- commit 959a93f
- NFS: add atomic_open for NFSv3 to handle O_TRUNC correctly
(bsc#1219847).
- commit 43a81fc
- scsi: qedf: Add pointer checks in qedf_update_link_speed()
(bsc#1220861 CVE-2021-47077).
- commit 499d19e
- Refresh patches.suse/0001-powerpc-pseries-memhp-Fix-access-beyond-end-of-drmem.patch.
Refresh patch metadata and sort.
- commit 15cb428
- ravb: Fix use-after-free issue in ravb_tx_timeout_work()
(bsc#1212514 CVE-2023-35827).
- team: fix null-ptr-deref when team device type is changed
(bsc#1220870 CVE-2023-52574).
- commit 36ef587
- net: mana: Fix TX CQE error handling (bsc#1220932
CVE-2023-52532).
- commit d388327
- Update reference of bpf-Fix-masking-negation-logic-upon-negative-dst-reg.patch
(bsc#1186484,CVE-2021-33200,bsc#1220700,CVE-2021-46974).
- commit d334f65
- nfsd: Do not refuse to serve out of cache (bsc#1220957).
- commit 828470f
- wifi: mac80211: fix potential key use-after-free (CVE-2023-52530
bsc#1220930).
- wifi: iwlwifi: mvm: Fix a memory corruption issue
(CVE-2023-52531 bsc#1220931).
- commit 4749167
- USB: serial: option: add Fibocom L7xx modules (git-fixes).
- commit 5053dd2
- USB: serial: option: don't claim interface 4 for ZTE MF290
(git-fixes).
- commit a0c4a2e
- usb: storage: set 1.50 as the lower bcdDevice for older "Super
Top" compatibility (git-fixes).
- commit 680e979
- net: nfc: fix races in nfc_llcp_sock_get() and
nfc_llcp_sock_get_sn() (CVE-2023-52502 bsc#1220831).
- commit d0dd97d
- tls: fix race between tx work scheduling and socket close
(CVE-2024-26585 bsc#1220187).
- commit 2d824be
- kabi: restore return type of dst_ops::gc() callback
(CVE-2023-52340 bsc#1219295).
- ipv6: remove max_size check inline with ipv4 (CVE-2023-52340
bsc#1219295).
- commit dd00c24
- netfilter: nf_tables: fix 64-bit load issue in
nft_byteorder_eval() (CVE-2024-0607 bsc#1218915).
- netfilter: nf_tables: fix pointer math issue in
nft_byteorder_eval() (CVE-2024-0607 bsc#1218915).
- commit b635ad7
- Update patches.suse/sctp-use-call_rcu-to-free-endpoint.patch
(CVE-2022-20154 CVE-2021-46929 bsc#1200599 bsc#1220482).
- commit 23c3231
- tomoyo: fix UAF write bug in tomoyo_write_control() (bsc#1220825
CVE-2024-26622).
- commit e934259
- doc/README.SUSE: Update information about module support status
(jsc#PED-5759)
Following the code change in SLE15-SP6 to have externally supported
modules no longer taint the kernel, update the respective documentation
in README.SUSE:
* Describe that support status can be obtained at runtime for each
module from /sys/module/$MODULE/supported and for the entire system
from /sys/kernel/supported. This provides a way how to now check that
the kernel has any externally supported modules loaded.
* Remove a mention that externally supported modules taint the kernel,
but keep the information about bit 16 (X) and add a note that it is
still tracked per module and can be read from
/sys/module/$MODULE/taint. This per-module information also appears in
Oopses.
- commit 9ed8107
- Bluetooth: hci_ll: don't call kfree_skb() under
spin_lock_irqsave() (git-fixes).
- commit 8e9750e
- Bluetooth: hci_h5: don't call kfree_skb() under
spin_lock_irqsave() (git-fixes).
- commit e3ec875
- locking/qrwlock: Fix ordering in queued_write_lock_slowpath()
(CVE-2021-46921 bsc#1220468 bsc#1185041).
- commit 9f2e845
- locking/barriers: Introduce smp_cond_load_relaxed() and
atomic_cond_read_relaxed() (bsc#1220468 bsc#1050549).
- commit 76b2073
- Bluetooth: hci_bcsp: don't call kfree_skb() under
spin_lock_irqsave() (git-fixes).
- commit 3114978
- Bluetooth: hci_qca: don't call kfree_skb() under
spin_lock_irqsave() (git-fixes).
- commit 40c2728
- Input: appletouch - initialize work before device registration
(CVE-2021-46932 bsc#1220444).
- commit 02010d5
- powerpc/pseries/memhp: Fix access beyond end of drmem array
(bsc#1220250,CVE-2023-52451).
- commit 22d7587
- ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe
failure (bsc#1220599 CVE-2021-46953).
- commit 69d8de2
- mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
(bsc#1220238 CVE-2023-52449).
- commit a845e8b
- Input: powermate - fix use-after-free in
powermate_config_complete (CVE-2023-52475 bsc#1220649).
- HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
(CVE-2023-52478 bsc#1220796).
- commit 6daf909
- i2c: Fix a potential use after free (bsc#1220409
CVE-2019-25162).
- commit 0be34df
- i2c: cadence: fix reference leak when pm_runtime_get_sync fails
(bsc#1220570 CVE-2020-36784).
- commit 8727379
- bus: qcom: Put child node before return (CVE-2021-47054
bsc#1220767).
- commit 0c0fa8d
- NFC: st21nfca: Fix memory leak in device probe and remove
(CVE-2021-46924 bsc#1220459).
- commit 01b7814
- netfilter: nft_limit: avoid possible divide error in
nft_limit_init (CVE-2021-46915 bsc#1220436).
- commit 9130a3d
- HID: usbhid: fix info leak in hid_submit_ctrl (CVE-2021-46906
bsc#1220421).
- commit 1d243b9
- media: pvrusb2: fix use after free on context disconnection
(CVE-2023-52445 bsc#1220241).
- commit f8f3542
- media: dvbdev: Fix memory leak in dvb_media_device_free()
(CVE-2020-36777 bsc#1220526).
- commit cd311ab
- apparmor: avoid crash when parsed profile name is empty
(CVE-2023-52443 bsc#1220240).
- commit 8387a56
- nfc: nci: fix possible NULL pointer dereference in
send_acknowledge() (bsc#1219125 CVE-2023-46343).
- commit 7ff1724
- md: bypass block throttle for superblock update (git-fixes).
- commit e6ba7c9
- tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd (bsc#1218450).
- commit 4a3997c
- netfilter: nftables: avoid overflows in nft_hash_buckets()
(CVE-2021-46992 bsc#1220638).
- commit c79b980
- netfilter: nft_set_hash: add nft_hash_buckets() (CVE-2021-46992
bsc#1220638).
- commit 5542c1b
- net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
(CVE-2021-47013 bsc#1220641).
- commit a848ac2
- net: fec: Better handle pm_runtime_get() failing in .remove()
(git-fixes).
- commit 60e6dbc
- net: fec: fix use-after-free in fec_drv_remove (git-fixes).
- commit 192ab42
- i40e: Fix use-after-free in i40e_client_subtask()
(CVE-2021-46991 bsc#1220575).
- commit 27d6f39
- KVM: s390: vsie: fix race during shadow creation (git-fixes
bsc#1220613).
- commit a2a5381
- s390: use the correct count for __iowrite64_copy() (git-fixes
bsc#1220607).
- commit 0823e37
- mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in
error path (bsc#1220344 CVE-2024-26595).
- commit 71c942e
- net: fec: fix clock count mis-match (git-fixes).
- commit 90008dd
- net: hns3: add compatible handling for MAC VLAN switch parameter
configuration (git-fixes).
- commit 9cbe2e0
- net: phy: initialise phydev speed and duplex sanely (git-fixes).
- commit 5fc404a
- bnx2x: Fix PF-VF communication over multi-cos queues
(git-fixes).
- commit 58f28c6
- ixgbe: protect TX timestamping from API misuse (git-fixes).
- commit c740900
- net: phy: dp83867: enable robust auto-mdix (git-fixes).
- commit 51f918b
- net: fec: add missed clk_disable_unprepare in remove
(git-fixes).
- commit 26193da
- e1000: fix memory leaks (git-fixes).
- commit 63cea05
- igb: Fix constant media auto sense switching when no cable is
connected (git-fixes).
- commit ecbd46c
- net: hisilicon: Fix usage of uninitialized variable in function
mdio_sc_cfg_reg_write() (git-fixes).
- commit 467a700
- net: hns3: not allow SSU loopback while execute ethtool -t dev
(git-fixes).
- commit feac716
- net/mlx5e: ethtool, Avoid setting speed to 56GBASE when autoneg
off (git-fixes).
- commit 38e0f13
- Update metadata
- commit fca1f53
- net: openvswitch: limit the number of recursions from action
sets (bsc#1219835 CVE-2024-1151).
- commit 9353f4f
- EDAC/thunderx: Fix possible out-of-bounds string access (bsc#1220330, CVE-2023-52464)
- commit a228c17
- rpm templates: Always define usrmerged
usrmerged is now defined in kernel-spec-macros and not the distribution.
Only check if it's defined in kernel-spec-macros, not everywhere where
it's used.
- commit a6ad8af
- KVM: x86: work around QEMU issue with synthetic CPUID leaves (git-fixes).
- commit 7dad6e2
- net: lpc-enet: fix printk format strings (git-fixes).
- commit dcd5e66
- net: tundra: tsi108: use spin_lock_irqsave instead of
spin_lock_irq in IRQ context (git-fixes).
- commit 3fddc2a
- net: hisilicon: Fix dma_map_single failed on arm64 (git-fixes).
- commit 65f9c53
- net: hisilicon: fix hip04-xmit never return TX_BUSY (git-fixes).
- commit b56984b
- net: hisilicon: make hip04_tx_reclaim non-reentrant (git-fixes).
- Refresh
patches.suse/net-hisilicon-Fix-ping-latency-when-deal-with-high-t.patch.
- commit 1de9297
- net: sfp: add mutex to prevent concurrent state checks
(git-fixes).
- commit 4badb38
- rpm templates: Move macro definitions below buildrequires
Many of the rpm macros defined in the kernel packages depend directly or
indirectly on script execution. OBS cannot execute scripts which means
values of these macros cannot be used in tags that are required for OBS
to see such as package name, buildrequires or buildarch.
Accumulate macro definitions that are not directly expanded by mkspec
below buildrequires and buildarch to make this distinction clear.
- commit 89eaf4c
- media: usb: dvd-usb: fix uninit-value bug in
dibusb_read_eeprom_byte() (git-fixes).
- commit 4772961
- media: uvcvideo: Set capability in s_param (git-fixes).
- commit df9234c
- media: dw2102: Fix use after free (git-fixes).
- commit 6909f5e
- media: dw2102: make dvb_usb_device_description structures const
(git-fixes).
- Refresh
patches.suse/media-dw2102-Fix-memleak-on-sequence-of-probes.patch.
- commit cfe8bf2
- media: dvb-usb: Add memory free on error path in dw2102_probe()
(git-fixes).
- Refresh
patches.suse/media-dw2102-Fix-memleak-on-sequence-of-probes.patch.
- commit 60bfc4d
- [media] media drivers: annotate fall-through (git-fixes).
- commit 550adce
- rpm/check-for-config-changes: add GCC_ASM_GOTO_OUTPUT_WORKAROUND to IGNORED_CONFIGS_RE
Introduced by commit 68fb3ca0e408 ("update workarounds for gcc "asm
goto" issue").
- commit be1bdab
- media: rc: ir-rc6-decoder: enable toggle bit for Kathrein
RCU-676 remote (git-fixes).
- commit 40a7cdd
- media: rc: do not remove first bit if leader pulse is present
(git-fixes).
- commit 055036d
- media: coda: reuse coda_s_fmt_vid_cap to propagate format in
coda_s_fmt_vid_out (git-fixes).
- commit 346be28
- media: coda: set min_buffers_needed (git-fixes).
- commit 9e4f67c
- media: coda: constify platform_device_id (git-fixes).
- commit da6a628
- media: coda: reduce iram size to leave space for suspend to ram
(git-fixes).
- commit 015f50d
- media: coda: explicitly request exclusive reset control
(git-fixes).
- commit 19dcce2
- media: coda: wake up capture queue on encoder stop after output
streamoff (git-fixes).
- Refresh
patches.suse/media-coda-fix-last-buffer-handling-in-V4L2_ENC_CMD_.patch.
- commit 4fba70d
- [media] coda: simplify optional reset handling (git-fixes).
- commit bc3f552
- [media] media: platform: coda: remove variable self assignment
(git-fixes).
- commit 6d6901a
- media: dvb-usb: dw2102: fix uninit-value in
su3000_read_mac_address (git-fixes).
- commit abccca4
- media: dvb-usb: m920x: Fix a potential memory leak in
m920x_i2c_xfer() (git-fixes).
- commit 4716702
- media: m920x: don't use stack on USB reads (git-fixes).
- commit 45368d1
- media: dw2102: Fix memleak on sequence of probes (git-fixes).
- commit d5c69b6
- rpm/scripts: Remove obsolete Symbols.list
Symbols.list is not longer needed by the new klp-convert implementation. (bsc#1218644)
- commit 596cf9f
- usb: musb: dsps: Fix the probe error path (git-fixes).
- commit 2f6dfb0
- usb: musb: tusb6010: check return value after calling
platform_get_resource() (git-fixes).
- commit 3b8e34e
- usb: musb: musb_dsps: request_irq() after initializing musb
(git-fixes).
- commit 9ef2688
- usb: host: fotg210: fix the actual_length of an iso packet
(git-fixes).
- commit bcd63df
- usb: host: fotg210: fix the endpoint's transactional
opportunities calculation (git-fixes).
- commit f16fc26
- compute-PATCHVERSION: Do not produce output when awk fails
compute-PATCHVERSION uses awk to produce a shell script that is
subsequently executed to update shell variables which are then printed
as the patchversion.
Some versions of awk, most notably bysybox-gawk do not understand the
awk program and fail to run. This results in no script generated as
output, and printing the initial values of the shell variables as
the patchversion.
When the awk program fails to run produce 'exit 1' as the shell script
to run instead. That prevents printing the stale values, generates no
output, and generates invalid rpm spec file down the line. Then the
problem is flagged early and should be easier to diagnose.
- commit 8ef8383
- x86/cpu, kvm: Move X86_FEATURE_LFENCE_RDTSC to its native leaf (git-fixes).
- commit 55e0925
- KVM: x86: Move open-coded CPUID leaf 0x80000021 EAX bit propagation code (git-fixes).
- commit aebeb2d
- KVM: x86: synthesize CPUID leaf 0x80000021h if useful (git-fixes).
- commit 9c96097
- KVM: x86: add support for CPUID leaf 0x80000021 (git-fixes).
- commit 5a997a6
- x86/asm: Add _ASM_RIP() macro for x86-64 (%rip) suffix (git-fixes).
- commit 54b16df
- KVM: VMX: Move VERW closer to VMentry for MDS mitigation (git-fixes).
- KVM: VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH (git-fixes).
- x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key (git-fixes).
Also add mds_user_clear to kABI severity as it's used purely for
mitigation so it's low risk.
- x86/entry_32: Add VERW just before userspace transition (git-fixes).
- x86/entry_64: Add VERW just before userspace transition (git-fixes).
- x86/bugs: Add asm helpers for executing VERW (bsc#1213456).
- commit 7cd11ce
- net/rds: Fix UBSAN: array-index-out-of-bounds in rds_cmsg_recv
(bsc#1219127 CVE-2024-23849).
- commit e941df3
- USB: hub: check for alternate port before enabling
A_ALT_HNP_SUPPORT (bsc#1218527).
- commit aaefb30
- kernel-binary: Move build script to the end
All other spec templates have the build script at the end, only
kernel-binary has it in the middle. Align with the other templates.
- commit 98cbdd0
- rpm templates: Aggregate subpackage descriptions
While in some cases the package tags, description, scriptlets and
filelist are located together in other cases they are all across the
spec file. Aggregate the information related to a subpackage in one
place.
- commit 8eeb08c
- net: bonding: debug: avoid printing debug logs when bond is
not notifying peers (git-fixes).
- commit f58ad69
- rpm templates: sort rpm tags
The rpm tags in kernel spec files are sorted at random.
Make the order of rpm tags somewhat more consistent across rpm spec
templates.
- commit 8875c35
- usb: typec: tcpci: clear the fault status bit (git-fixes).
- commit fbeda7b
- PCI: Prevent xHCI driver from claiming AMD VanGogh USB3 DRD
device (git-fixes).
- commit 2012056
- Update to add CVE-2024-23851 tag,
patches.suse/dm-limit-the-number-of-targets-and-parameter-size-ar.patch
(bsc#1219827, bsc#1219146, CVE-2023-52429, CVE-2024-23851).
- commit 7dd5c42
- audit: fix possible soft lockup in __audit_inode_child()
(git-fixes).
- commit a347e97
- ASN.1: Fix check for strdup() success (git-fixes).
- commit 26b2327
- dm: limit the number of targets and parameter size area
(bsc#1219827, bsc#1219146, CVE-2023-52429).
- commit 3ddaf98
- Update
patches.suse/nvmet-tcp-fix-a-crash-in-nvmet_req_complete.patch
(bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
CVE-2023-6356).
- commit 1a6bd68
- nvmet-tcp: Fix the H2C expected PDU len calculation
(bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
CVE-2023-6356).
- nvmet-tcp: remove boilerplate code (bsc#1217987 bsc#1217988
bsc#1217989 CVE-2023-6535 CVE-2023-6536 CVE-2023-6356).
- nvmet-tcp: Fix a kernel panic when host sends an invalid H2C
PDU length (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535
CVE-2023-6536 CVE-2023-6356).
- commit 3e8a84f
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
Simple arithmetic fix.
- commit df1ea97
- vhost: use kzalloc() instead of kmalloc() followed by memset()
(CVE-2024-0340, bsc#1218689).
- commit 265772f
- kernel-binary: certs: Avoid trailing space
- commit bc7dc31
- mlx4: handle non-napi callers to napi_poll (git-fixes).
- commit 13aca9d
- bnxt_en: Log unknown link speed appropriately (git-fixes).
- commit cab91f3
- net/mlx5: Don't call timecounter cyc2time directly from 1PPS flow (git-fixes).
- commit 30b8d5c
- net: mvneta: fix double free of txq->buf (git-fixes).
- commit abfb85a
- r8169: fix data corruption issue on RTL8402 (git-fixes).
- commit a389731
- rpm/kernel-binary.spec.in: install scripts/gdb when enabled in config
(bsc#1219653)
They are put into -devel subpackage. And a proper link to
/usr/share/gdb/auto-load/ is created.
- commit 1dccf2a
- net: stmmac: dwmac1000: fix out-of-bounds mac address reg
setting (git-fixes).
- commit 51f13e8
- net: fec: Do not use netdev messages too early (git-fixes).
- commit 24b07f8
- net: stmmac: dwmac4/5: Clear unused address entries (git-fixes).
- commit 156e8fc
- net: stmmac: dwmac1000: Clear unused address entries
(git-fixed).
- commit b89c3f6
- net: dsa: mv88e6xxx: avoid error message on remove from VLAN 0
(git-fixed).
- commit 63f7ed7
- net: xilinx: fix possible object reference leak (git-fixed).
- commit 0884dff
- net: macb: Add null check for PCLK and HCLK (git-fixed).
- Refresh
patches.suse/0006-net-macb-fix-error-format-in-dev_err.patch.
- commit 1fdfc75
- netfilter: nf_tables: reject QUEUE/DROP verdict parameters
(CVE-2024-1086 bsc#1219434).
- commit 1f42903
- configfs: fix a use-after-free in __configfs_open_file
(git-fixes).
- commit 839bbef
- chardev: fix error handling in cdev_device_add() (git-fixes).
- commit 76071ad
- fs: don't audit the capability check in simple_xattr_list()
(git-fixes).
- commit 32c621d
- pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP
(git-fixes).
- commit 165619a
- pstore/ram: Fix error return code in ramoops_probe()
(git-fixes).
- commit 6c26e9c
- kernfs: fix use-after-free in __kernfs_remove (git-fixes).
- commit 1e4394d
- kernfs: Separate kernfs_pr_cont_buf and rename_lock (git-fixes).
- commit 302cbf3
- configfs: fix a race in configfs_{,un}register_subsystem()
(git-fixes).
- commit ff1ac8a
- vfs: make freeze_super abort when sync_filesystem returns error
(git-fixes).
- commit a0e15ea
- fs: orangefs: fix error return code of
orangefs_revalidate_lookup() (git-fixes).
- commit 05692b2
- fs: warn about impending deprecation of mandatory locks
(git-fixes).
- commit d313c61
- configfs: fix memleak in configfs_release_bin_file (git-fixes).
- commit e182771
- 9p: missing chunk of "fs/9p: Don't update file type when
updating file attributes" (git-fixes).
- commit d7f7957
- kernfs: bring names in comments in line with code (git-fixes).
- commit b2412a4
- configfs: fix config_item refcnt leak in configfs_rmdir()
(git-fixes).
- commit a4e6173
- help_next should increase position index (git-fixes).
- commit a734d52
- configfs: fix a deadlock in configfs_symlink() (git-fixes).
- commit 31f30f9
- locks: print a warning when mount fails due to lack of "mand"
support (git-fixes).
- commit 4a54942
- configfs: provide exclusion between IO and removals (git-fixes).
- commit be9e3af
- configfs: new object reprsenting tree fragments (git-fixes).
- commit 727fecd
- configfs: stash the data we need into configfs_buffer at open
time (git-fixes).
- commit 57d5998
- pstore/ram: Run without kernel crash dump region (git-fixes).
- Refresh patches.suse/pstore-backend-autoaction.
- commit 27a20a7
- fs/file.c: initialize init_files.resize_wait (git-fixes).
- commit 4e99111
- fs: ratelimit __find_get_block_slow() failure message
(git-fixes).
- commit 066abb3
- iomap: sub-block dio needs to zeroout beyond EOF (git-fixes).
- commit c176969
- fs/fat/fatent.c: add cond_resched() to fat_count_free_clusters()
(git-fixes).
- commit 97bf06c
- proc: fix /proc/*/map_files lookup (git-fixes).
- commit 66524a9
- pstore: ram_core: fix possible overflow in
persistent_ram_init_ecc() (git-fixes).
- commit 3b8a874
- pstore/ram: Check start of empty przs during init (git-fixes).
- commit 86b8610
- statfs: enforce statfs[64] structure initialization (git-fixes).
- commit e9ab62b
- aio: fix mremap after fork null-deref (git-fixes).
- commit f633071
- drm/amdgpu: Fix potential fence use-after-free v2 (bsc#1219128
CVE-2023-51042).
- commit 78c123f
- rpm/mkspec: sort entries in _multibuild
Otherwise it creates unnecessary diffs when tar-up-ing. It's of course
due to readdir() using "random" order as served by the underlying
filesystem.
See for example:
https://build.opensuse.org/request/show/1144457/changes
- commit d1155de
- nvmet-tcp: fix a crash in nvmet_req_complete() (git-fixes).
- commit 45b3590
- scsi: qla0xxx: Fix system crash due to bad pointer access
(git-fixes).
- commit 9c33792
- atm: Fix Use-After-Free in do_vcc_ioctl (CVE-2023-51780
bsc#1218730).
- commit 42f1cd3
- mm,mremap: bail out earlier in mremap_to under map pressure
(bsc#1123986).
- commit d63623c
- xen-netback: don't produce zero-size SKB frags (CVE-2023-46838,
XSA-448, bsc#1218836).
- commit 6d25bad
- USB: serial: option: fix FM101R-GL defines (git-fixes).
- commit c34221c
- libceph: use kernel_connect() (bsc#1219446).
- ceph: fix incorrect revoked caps assert in ceph_fill_file_size()
(bsc#1219445).
- commit 92ba85d
- USB: serial: option: add Fibocom to DELL custom modem FM101R-GL
(git-fixes).
- commit 9c63fba
- USB: serial: option: add entry for Sierra EM9191 with new
firmware (git-fixes).
- commit e18b083
- USB: serial: option: add Telit LE910C4-WWX 0x1035 composition
(git-fixes).
- commit 3c25206
- ext4: fix kernel BUG in 'ext4_write_inline_data_end()'
(CVE-2021-33631 bsc#1219412).
- commit 019d3a9
- kernel-source: Fix description typo
- commit 8abff35
- tracing/trigger: Fix to return error if failed to alloc snapshot
(git-fixes).
- commit 57e8982
- wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
(CVE-2023-47233 bsc#1216702).
- commit d2e0155
- net: stmmac: don't overwrite discard_frame status (git-fixes).
- commit af86f48
- net: ethernet: ti: fix possible object reference leak
(git-fixes).
- commit 8292c78
- rpm/constraints.in: set jobs for riscv to 8
The same workers are used for x86 and riscv and the riscv builds take
ages. So align the riscv jobs count to x86.
- commit b2c82b9
- net: ks8851: Set initial carrier state to down (git-fixes).
- commit 667be0a
- net: ks8851: Delay requesting IRQ until opened (git-fixes).
- commit 605f94a
- net: ks8851: Reassert reset pin if chip ID check fails
(git-fixes).
- commit 93e9e83
- net: dsa: qca8k: Enable delay for RGMII_ID mode (git-fixes).
- commit 94c1dc4
- net: dsa: mv88e6xxx: Work around mv886e6161 SERDES missing
MII_PHYSID2 (git-fixes).
- commit d97991c
- x86/unwind/orc: Fix unreliable stack dump with gcov (git-fixes).
- commit db29225
- x86/pm: Add enumeration check before spec MSRs save/restore setup (git-fixes).
- commit 0b71917
- x86/kvm/lapic: always disable MMIO interface in x2APIC mode (git-fixes).
- commit 42aa4b1
- x86/purgatory: Don't generate debug info for purgatory.ro (git-fixes).
- commit ad7d236
- x86/cpu: Add another Alder Lake CPU to the Intel family (git-fixes).
- commit 5e43536
- x86/build: Turn off -fcf-protection for realmode targets (git-fixes).
- commit 06f5589
- x86/build: Treat R_386_PLT32 relocation as R_386_PC32 (git-fixes).
- commit c5cf689
- x86/lib: Fix overflow when counting digits (git-fixes).
- commit 0070bad
- x86/asm: Ensure asm/proto.h can be included stand-alone (git-fixes).
- commit b6c5df9
- x86: __always_inline __{rd,wr}msr() (git-fixes).
- commit 8507f62
- x86: Mark stop_this_cpu() __noreturn (git-fixes).
- commit 47a8413
- x86: Clear .brk area at early boot (git-fixes).
- commit 63c0fc3
- mkspec: Use variant in constraints template
Constraints are not applied consistently with kernel package variants.
Add variant to the constraints template as appropriate, and expand it
in mkspec.
- commit cc68ab9
- rpm/constraints.in: add static multibuild packages
Commit 841012b049a5 (rpm/mkspec: use kernel-source: prefix for
constraints on multibuild) added "kernel-source:" prefix to the
dynamically generated kernels. But there are also static ones like
kernel-docs. Those fail to build as the constraints are still not
applied.
So add the prefix also to the static ones.
Note kernel-docs-rt is given kernel-source-rt prefix. I am not sure it
will ever be multibuilt...
- commit c2e0681
- drm/atomic: Fix potential use-after-free in nonblocking commits
(bsc#1219120 CVE-2023-51043).
- commit a69e3d8
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
Adjust the cpuid check when applying alternatives. Fixes false BUG_ON
in the presence of extra bugints/capints.
- commit 48af78f
- Revert "Limit kernel-source build to architectures for which the kernel binary"
This reverts commit 08a9e44c00758b5f3f3b641830ab6affff041132.
The fix for bsc#1108281 directly causes bsc#1218768, revert.
- commit 2943b8a
- mkspec: Include constraints for both multibuild and plain package always
There is no need to check for multibuild flag, the constraints can be
always generated for both cases.
- commit 308ea09
- rpm/mkspec: use kernel-source: prefix for constraints on multibuild
Otherwise the constraints are not applied with multibuild enabled.
- commit 841012b
- rpm/kernel-source.rpmlintrc: add action-ebpf
Upstream commit a79d8ba734bd (selftests: tc-testing: remove buildebpf
plugin) added this precompiled binary blob. Adapt rpmlintrc for
kernel-source.
- commit b5ccb33
- Refresh patches.suse/mce-fix-set_mce_nospec-to-always-unmap-the-whole-page.patch.
- commit 97df026
- usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer
(git-fixes).
- commit f9ab50f
- scsi: qedf: fc_rport_priv reference counting fixes
(bsc#1212152).
Refresh:
- patches.suse/scsi-qedf-correctly-handle-refcounting-of-rdata
- patches.suse/scsi-qedf-print-message-during-bailout-conditions
- patches.suse/scsi-qedf-print-scsi_cmd-backpointer-in-good-completion-path-if-the-command-is-still-being-used
- commit e171158
- ext4: silence the warning when evicting inode with
dioread_nolock (bsc#1206889).
- commit 3433e7a
- writeback: Export inode_io_list_del() (bsc#1216989).
patches/patches.suse/writeback-Protect-inode-i_io_list-with-inode-i_lock.patch:
Refresh
- commit c969261
- ext4: improve error recovery code paths in __ext4_remount()
(bsc#1213017 bsc#1219053 CVE-2024-0775).
- commit 3bb0d48
- Update
patches.suse/ext4-improve-error-recovery-code-paths-in-__ext4_rem.patch
(bsc#1213017 bsc#1219053 CVE-2024-0775).
- commit a5b396b
- scripts/tar-up.sh: don't add spurious entry from kernel-sources.changes.old
The previous change added the manual entry from kernel-sources.change.old
to old_changelog.txt unnecessarily. Let's fix it.
- commit fb033e8
- Refresh
patches.suse/ipmi-Cleanup-oops-on-initialization-failure.patch.
Alt-commit added
- commit 5093b56
- x86: Pin task-stack in __get_wchan() (git-fixes).
- commit 96f1d7b
- rpm/kernel-docs.spec.in: fix build with 6.8
Since upstream commit f061c9f7d058 (Documentation: Document each netlink
family), the build needs python yaml.
- commit 6a7ece3
- x86: Fix __get_wchan() for !STACKTRACE (git-fixes).
- commit 23a1a0e
- asix: Add check for usbnet_get_endpoints (git-fixes).
- commit d1fcea8
- x86/mce: relocate set{clear}_mce_nospec() functions (git-fixes).
- commit d9f49bd
- x86/CPU/AMD: Check vendor in the AMD microcode callback (git-fixes).
- commit 79b1f36
- mce: fix set_mce_nospec to always unmap the whole page (git-fixes).
- commit 2dcf8c9
- x86/alternatives: Sync core before enabling interrupts (git-fixes).
- commit d500914
- x86/cpu/hygon: Fix the CPU topology evaluation for real (git-fixes).
- commit 01e7093
- x86/kvm: Do not try to disable kvmclock if it was not enabled (git-fixes).
- commit 293b127
- x86: Fix get_wchan() to support the ORC unwinder (git-fixes).
- commit 1693c4c
- x86/pat: Pass valid address to sanitize_phys() (git-fixes).
- commit 9776480
- x86/pat: Fix x86_has_pat_wp() (git-fixes).
- blacklist.conf:
- commit 0a8ce61
- x86/mm: Add a x86_has_pat_wp() helper (git-fixes).
- commit 794f377
- veth: Fixing transmit return status for dropped packets
(git-fixes).
- commit c39655b
- preserve KABI for struct sfp_socket_ops (git-fixes).
- commit 58a9bc4
- blacklist.conf:
- Delete
patches.suse/NFSD-Fix-possible-sleep-during-nfsd4_release_lockown.patch.
This patch is harmful on all kernels, and irrelevant on kernels before
v5.4
bsc#1218968
- commit 5365a0a
- KVM: s390: vsie: Fix STFLE interpretive execution identification
(git-fixes bsc#1219022).
- commit 16098a4
- net: phylink: avoid resolving link state too early (git-fixes).
- commit 67b00b5
- gtp: change NET_UDP_TUNNEL dependency to select (git-fixes).
- commit dd6be0d
- mlxsw: spectrum: Avoid -Wformat-truncation warnings (git-fixes).
- commit bd062d1
- mlxsw: spectrum: Set LAG port collector only when active (git-fixes).
- commit 42cb04e
- net: mv643xx_eth: disable clk on error path in mv643xx_eth_shared_probe() (git-fixes).
- commit 5db0cbe
- net: systemport: Fix reception of BPDUs (git-fixes).
- commit 54f0189
- sfc: initialise found bitmap in efx_ef10_mtd_probe (git-fixes).
- commit 36c912f
- net: sfp: do not probe SFP module before we're attached (git-fixes).
- commit b335b5c
- net: phy: sfp: warn the user when no tx_disable pin is available (git-fixes).
- commit 921c51c
- net: stmmac: Disable EEE mode earlier in XMIT callback
(git-fixes).
- commit 42ea2f4
- preserve KABI for struct plat_stmmacenet_data (git-fixes).
- commit be0b5cc
- net: stmmac: Fallback to Platform Data clock in Watchdog
conversion (git-fixes).
- commit c0e8ae4
- net: stmmac: dwmac-rk: fix error handling in rk_gmac_powerup()
(git-fixes).
- commit 1f97aba
- net: dsa: bcm_sf2: Propagate error value from mdio_write
(git-fixes).
- commit 042ff8c
- net: (cpts) fix a missing check of clk_prepare (git-fixes).
- commit a0511a4
- mlxsw: spectrum: Properly cleanup LAG uppers when removing
port from LAG (git-fixes).
- commit 65b3a7e
- nfsd: drop st_mutex and rp_mutex before calling
move_to_close_lru() (bsc#1217525).
- commit d08e536
- libnvdimm/of_pmem: Use devm_kstrdup instead of kstrdup and
check its return value (git-fixes).
- nvdimm: Fix badblocks clear off-by-one error (git-fixes).
- nvdimm: Allow overwrite in the presence of disabled dimms
(git-fixes).
- nvdimm/btt: do not call del_gendisk() if not needed (git-fixes).
- libnvdimm/region: Fix label activation vs errors (git-fixes).
- commit dc5bee2
- libnvdimm: cover up changes in struct nvdimm_bus_descriptor
(git-fixes).
- libnvdimm: Validate command family indices (git-fixes).
- commit 27f581b
- libnvdimm: Out of bounds read in __nd_ioctl() (git-fixes).
- acpi/nfit: improve bounds checking for 'func' (git-fixes).
- libnvdimm/btt: fix variable 'rc' set but not used (git-fixes).
- libnvdimm/pmem: Delete include of nd-core.h (git-fixes).
- =?UTF-8?q?libnvdimm:=20Fix=20endian=20conversion=20issues?=
=?UTF-8?q?=C2=A0?= (git-fixes).
- libnvdimm: Fix compilation warnings with W=1 (git-fixes).
- libnvdimm/pmem: fix a possible OOB access when read and write
pmem (git-fixes).
- libnvdimm/btt: Fix a kmemdup failure check (git-fixes).
- libnvdimm/namespace: Fix a potential NULL pointer dereference
(git-fixes).
- libnvdimm/btt: Fix LBA masking during 'free list' population
(git-fixes).
- libnvdimm/btt: Remove unnecessary code in btt_freelist_init
(git-fixes).
- acpi/nfit: Require opt-in for read-only label configurations
(git-fixes).
- UAPI: ndctl: Fix g++-unsupported initialisation in headers
(git-fixes).
- commit e6b26fa
- s390/dasd: fix double module refcount decrement (bsc#1141539).
- commit 1d573b9
- netfilter: nf_tables: Reject tables of unsupported family
(CVE-2023-6040 bsc#1218752).
- commit 9e6d9d4
- net/rose: Fix Use-After-Free in rose_ioctl (CVE-2023-51782
bsc#1218757).
- commit 5e6770d
- powerpc/pseries/memhotplug: Quieten some DLPAR operations
(bsc#1065729).
- commit 4d451a9
- powerpc/powernv: Add a null pointer check in
opal_powercap_init() (bsc#1181674 ltc#189159 git-fixes).
- powerpc/powernv: Add a null pointer check in opal_event_init()
(bsc#1065729).
- powerpc/pseries/memhp: Fix access beyond end of drmem array
(bsc#1065729).
- powerpc: Don't clobber f0/vs0 during fp|altivec register save
(bsc#1065729).
- commit d5de04b
- Store the old kernel changelog entries in kernel-docs package (bsc#1218713)
The old entries are found in kernel-docs/old_changelog.txt in docdir.
rpm/old_changelog.txt can be an optional file that stores the similar
info like rpm/kernel-sources.changes.old. It can specify the commit
range that have been truncated. scripts/tar-up.sh expands from the
git log accordingly.
- commit c9a2566
- fs: ocfs2: namei: check return value of ocfs2_add_entry()
(git-fixes).
- commit 37053b5
- orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()
(git-fixes).
- commit 22c7474
- orangefs: Fix sysfs not cleanup when dev init failed
(git-fixes).
- commit 3dc6f72
- fat: add ratelimit to fat*_ent_bread() (git-fixes).
- commit 2e4dd8d
- orangefs: fix orangefs df output (git-fixes).
- commit 14af1e9
- fs/fat/file.c: issue flush after the writeback of FAT
(git-fixes).
- commit 4b5cf8c
- fs/exofs: fix potential memory leak in mount option parsing
(git-fixes).
- commit c3e2f19
- orangefs: rate limit the client not running info message
(git-fixes).
- commit 9ffd7ce
- gfs2: ignore negated quota changes (git-fixes).
- commit 65c2047
- gfs2: Fix possible data races in gfs2_show_options()
(git-fixes).
- commit 57d66df
- gfs2: Fix inode height consistency check (git-fixes).
- commit d7ee5ae
- gfs2: Check sb_bsize_shift after reading superblock (git-fixes).
- commit 381ce29
- gfs2: Make sure FITRIM minlen is rounded up to fs block size
(git-fixes).
- commit 59f59dc
- gfs2: assign rgrp glock before compute_bitstructs (git-fixes).
- commit 8e79a5c
- gfs2: Don't call dlm after protocol is unmounted (git-fixes).
- commit 0e0a651
- gfs2: Fix use-after-free in gfs2_glock_shrink_scan (git-fixes).
- commit 4dff329
- gfs2: report "already frozen/thawed" errors (git-fixes).
- commit e5108bb
- gfs2: Don't skip dlm unlock if glock has an lvb (git-fixes).
- commit 38230f9
- gfs2: check for empty rgrp tree in gfs2_ri_update (git-fixes).
- commit 3484422
- gfs2: Wake up when sd_glock_disposal becomes zero (git-fixes).
- commit 6e96bc8
- gfs2: check for live vs. read-only file system in gfs2_fitrim
(git-fixes).
- commit dece8b9
- gfs2: Free rd_bits later in gfs2_clear_rgrpd to fix
use-after-free (git-fixes).
- commit 5f11647
- gfs2: add validation checks for size of superblock (git-fixes).
- commit 4bfdec0
- gfs2: fix use-after-free on transaction ail lists (git-fixes).
- commit 3c0934a
- gfs2: initialize transaction tr_ailX_lists earlier (git-fixes).
- commit a3dcb8b
- gfs2: Allow lock_nolock mount to specify jid=X (git-fixes).
- commit c3d10eb
- gfs2_atomic_open(): fix O_EXCL|O_CREAT handling on cold dcache
(git-fixes).
- commit 50b2782
- gfs2: clear buf_in_tr when ending a transaction in
sweep_bh_for_rgrps (git-fixes).
- commit 0638ce6
- gfs2: Fix sign extension bug in gfs2_update_stats (git-fixes).
- commit 6905d0e
- gfs2: Fix lru_count going negative (git-fixes).
- commit 22c6d6f
- gfs2: take jdata unstuff into account in do_grow (git-fixes).
- commit f6cafad
- gfs2: Fix marking bitmaps non-full (git-fixes).
- commit 27f21b4
- GFS2: Flush the GFS2 delete workqueue before stopping the
kernel threads (git-fixes).
- commit c0d61c2
- gfs2: Don't set GFS2_RDF_UPTODATE when the lvb is updated
(git-fixes).
- commit ca05c1f
- gfs2: Special-case rindex for gfs2_grow (git-fixes).
- commit 77ffe3d
- reiserfs: Replace 1-element array with C99 style flex-array
(git-fixes).
- commit ed361ae
- reiserfs: Check the return value from __getblk() (git-fixes).
- commit c984c17
- affs: fix basic permission bits to actually work (git-fixes).
- commit 6abe668
- PCI: Disable ATS for specific Intel IPU E2000 devices
(bsc#1218622).
- commit 6c47e22
- Fix build error in debug config
- commit f49e139
- smb: client: fix potential OOB in smb2_dump_detail()
(bsc#1217946 CVE-2023-6610).
- commit 04b527b
- smb: client: fix potential OOB in smb2_dump_detail()
(bsc#1217946 CVE-2023-6610).
- commit 74aafd7
- Limit kernel-source build to architectures for which the kernel binary
is built (bsc#1108281).
- commit 08a9e44
- netfilter: nf_tables: do not allow RULE_ID to refer to another chain (bsc#1202095 CVE-2022-2586).
- commit 32951b9
- netfilter: nf_tables: do not allow SET_ID to refer to another table (bsc#1202095 CVE-2022-2586).
- commit d107d27
- netfilter: preserve KABI for struct nft_set (bsc#1202095 CVE-2022-2586).
- commit b3d22c5
- netfilter: nf_tables: pass ctx to nf_tables_expr_destroy() (bsc#1202095 CVE-2022-2586).
- commit 61a0caa
- Resolve build warnings from previous series due to missing commit for
Ice Lake freerunning counters
perf/x86/intel/uncore: Add box_offsets for free-running counters
(jsc#PED-5023 bsc#1211439).
- commit 8524ea3
- Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg
(CVE-2023-51779 bsc#1218559).
- commit f63e944
- xhci: Clear EHB bit only at end of interrupt handler
(git-fixes).
- commit 21f5e35
- usb: config: fix iteration issue in 'usb_get_bos_descriptor()'
(git-fixes).
- commit d5b5186
- md/raid1: fix error: ISO C90 forbids mixed declarations
(git-fixes).
- commit c63e55d
- dm-integrity: don't modify bio's immutable bio_vec in
integrity_metadata() (git-fixes).
- md: don't leave 'MD_RECOVERY_FROZEN' in error path of
md_set_readonly() (git-fixes).
- bcache: revert replacing IS_ERR_OR_NULL with IS_ERR (git-fixes).
- dm-verity: align struct dm_verity_fec_io properly (git-fixes).
- dm verity: don't perform FEC for failed readahead IO
(git-fixes).
- bcache: add code comments for bch_btree_node_get() and
__bch_btree_node_alloc() (git-fixes).
- bcache: replace a mistaken IS_ERR() by IS_ERR_OR_NULL() in
btree_gc_coalesce() (git-fixes).
- bcache: prevent potential division by zero error (git-fixes).
- bcache: check return value from btree_node_alloc_replacement()
(git-fixes).
- md/raid1: hold the barrier until handle_read_error() finishes
(git-fixes).
- md/raid1: free the r1bio before waiting for blocked rdev
(git-fixes).
- md: raid1: fix potential OOB in raid1_remove_disk() (git-fixes).
- md: restore 'noio_flag' for the last mddev_resume() (git-fixes).
- dm cache policy smq: ensure IO doesn't prevent cleaner policy
progress (git-fixes).
- dm raid: fix missing reconfig_mutex unlock in raid_ctr()
error paths (git-fixes).
- md/raid0: add discard support for the 'original' layout
(git-fixes).
- bcache: Fix __bch_btree_node_alloc to make the failure behavior
consistent (git-fixes).
- bcache: Remove unnecessary NULL point check in node allocations
(git-fixes).
- nbd: Add the maximum limit of allocated index in nbd_dev_add
(git-fixes).
- nbd: Fix debugfs_create_dir error checking (git-fixes).
- dm flakey: fix a crash with invalid table line (git-fixes).
- dm integrity: call kmem_cache_destroy() in dm_integrity_init()
error path (git-fixes).
- dm verity: fix error handling for check_at_most_once on FEC
(git-fixes).
- dm stats: check for and propagate alloc_percpu failure
(git-fixes).
- dm crypt: add cond_resched() to dmcrypt_write() (git-fixes).
- rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create()
fails (git-fixes).
- dm cache: add cond_resched() to various workqueue loops
(git-fixes).
- dm thin: add cond_resched() to various workqueue loops
(git-fixes).
- dm: remove flush_scheduled_work() during local_exit()
(git-fixes).
- dm flakey: fix logic when corrupting a bio (git-fixes).
- dm flakey: don't corrupt the zero page (git-fixes).
- dm verity: skip redundant verity_handle_err() on I/O errors
(git-fixes).
- commit 640b528
- Previous perf cve-4.12->SLE12-SP5 manual merge was incorrect. Fix.
- Refresh
patches.suse/perf-Fix-perf_event_validate_size-lockdep-splat.patch.
- Refresh patches.suse/perf-Fix-perf_event_validate_size.patch.
- commit 3382aa6
- mkspec: Add multibuild support (JSC-SLE#5501, boo#1211226, bsc#1218184)
When MULTIBUILD option in config.sh is enabled generate a _multibuild
file listing all spec files.
- commit f734347
- Build in the correct KOTD repository with multibuild
(JSC-SLE#5501, boo#1211226, bsc#1218184)
With multibuild setting repository flags is no longer supported for
individual spec files - see
https://github.com/openSUSE/open-build-service/issues/3574
Add ExclusiveArch conditional that depends on a macro set up by
bs-upload-kernel instead. With that each package should build only in
one repository - either standard or QA.
Note: bs-upload-kernel does not interpret rpm conditionals, and only
uses the first ExclusiveArch line to determine the architectures to
enable.
- commit aa5424d
- net: usb: qmi_wwan: claim interface 4 for ZTE MF290 (git-fixes).
- commit 0feae40
- Fix termination state for idr_for_each_entry_ul() (bsc#1109837).
- commit d343735
- Bluetooth: avoid memcmp() out of bounds warning (bsc#1215237
CVE-2020-26555).
- Bluetooth: hci_event: Fix coding style (bsc#1215237
CVE-2020-26555).
- Bluetooth: hci_event: Fix using memcmp when comparing keys
(bsc#1215237 CVE-2020-26555).
- commit eb3189f
- Bluetooth: Reject connection with the device which has same
BD_ADDR (bsc#1215237 CVE-2020-26555).
- commit fea8835
- Bluetooth: hci_event: Ignore NULL link key (bsc#1215237
CVE-2020-26555).
- commit c0e1033
- perf/x86/intel/uncore: Fix reference count leak in
__uncore_imc_init_box() (jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix reference count leak in
snr_uncore_mmio_map() (jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix broken read_counter() for SNB IMC
PMU (jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix CAS_COUNT_WRITE issue for ICX
(jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix IIO event constraints for Snowridge
(jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix Intel ICX IIO event constraints
(jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Support extra IMC channel on Ice Lake
server (jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix integer overflow on 23 bit left
shift of a u32 (jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix M2M event umask for Ice Lake server
(jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix the scale of the IMC free-running
events (jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix oops when counting IMC uncore events
on some TGL (jsc#PED-5023 bsc#1211439 (git-fixes)).
- perf/x86/intel/uncore: Fix missing marker for
snr_uncore_imc_freerunning_events (jsc#PED-5023 bsc#1211439
(git-fixes)).
- commit 1cc4e6d
- perf: Fix perf_event_validate_size() lockdep splat
(CVE-2023-6931 bsc#1218258).
- perf: Fix perf_event_validate_size() (CVE-2023-6931
bsc#1218258).
- commit 6cfe60a
- smb: client: fix OOB in smbCalcSize() (bsc#1217947
CVE-2023-6606).
- commit d398d5f
- smb: client: fix OOB in smbCalcSize() (bsc#1217947
CVE-2023-6606).
- commit 6765acb
- perf/x86/intel/uncore: Add Rocket Lake support (jsc#PED-5023
bsc#1211439).
- commit 60ab65b
- perf/x86/msr: Add Rocket Lake CPU support (jsc#PED-5023
bsc#1211439).
- commit fac3f56
- perf/x86/msr: Add Tiger Lake CPU support (jsc#PED-5023
bsc#1211439).
- commit 7c0409f
- perf/x86/cstate: Add Rocket Lake CPU support (jsc#PED-5023
bsc#1211439).
- commit f918ead
- perf/x86/cstate: Add Tiger Lake CPU support (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit c544da1
- perf/x86/intel: Add Rocket Lake CPU support (jsc#PED-5023
bsc#1211439).
- commit 5b98b63
- perf/x86/intel: Add Tiger Lake CPU support (jsc#PED-5023
bsc#1211439).
- commit 0e12a3f
- perf/x86/intel: Fix Ice Lake event constraint table
(jsc#PED-5023 bsc#1211439).
- commit cd283d5
- perf/x86/intel/uncore: Update Ice Lake uncore units
(jsc#PED-5023 bsc#1211439).
- commit 0e10240
- perf/x86/intel/uncore: Split the Ice Lake and Tiger Lake MSR
uncore support (jsc#PED-5023 bsc#1211439).
- commit 9c5fb1a
- x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to
the to Intel CPU family (jsc#PED-5023 bsc#1211439).
- blacklist.conf:
- commit 2561a0a
- perf/x86/intel/uncore: Add Comet Lake support (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit 2e1087f
- x86/cpu: Add Sapphire Rapids CPU model number (jsc#PED-5023
bsc#1211439).
- commit 5b5d85f
- perf/x86/rapl: Add Ice Lake RAPL support (jsc#PED-5023
bsc#1211439).
- commit c6183ea
- perf/x86/intel/uncore: Add Ice Lake server uncore support
(jsc#PED-5023 bsc#1211439).
- commit 4150606
- perf/x86/intel/uncore: Factor out __snr_uncore_mmio_init_box
(jsc#PED-5023 bsc#1211439).
- commit c73e167
- perf/x86: Add Intel Tiger Lake uncore support (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/x86-intel-aggregate-big-core-mobile-naming.patch.
- Refresh
patches.suse/x86-intel-aggregate-microserver-naming.patch.
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit f5492f0
- perf/x86/cstate: Update C-state counters for Ice Lake
(jsc#PED-5023 bsc#1211439).
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit fef0544
- perf/x86/msr: Add new CPU model numbers for Ice Lake
(jsc#PED-5023 bsc#1211439).
- Refresh
patches.suse/x86-bugs-Report-AMD-retbleed-vulnerability.patch.
- Refresh
patches.suse/x86-bugs-Report-Intel-retbleed-vulnerability.patch.
- Refresh
patches.suse/x86-bugs-add-cannon-lake-to-retbleed-affected-cpu-list.patch.
- Refresh
patches.suse/x86-common-Stamp-out-the-stepping-madness.patch.
- Refresh
patches.suse/x86-intel-aggregate-microserver-naming.patch.
- Refresh
patches.suse/x86-speculation-Mark-all-Skylake-CPUs-as-vulnerable-to-GDS.patch.
- Refresh
patches.suse/x86-speculation-add-gather-data-sampling-mitigation.patch.
- Refresh
patches.suse/x86-speculation-mmio-Enumerate-Processor-MMIO-Stale-Data-bug.patch.
- Refresh
patches.suse/x86-speculation-mmio-Reuse-SRBDS-mitigation-for-SBDS.patch.
- commit 68588a6
- perf/x86/msr: Add Comet Lake CPU support (jsc#PED-5023
bsc#1211439).
- commit 2ec338b
- x86/cpu: Add Comet Lake to the Intel CPU models header
(jsc#PED-5023 bsc#1211439).
- blacklist.conf:
- commit bd3eac7
- x86/cpu: Add Tiger Lake to Intel family (jsc#PED-5023
bsc#1211439).
- blacklist.conf:
- Refresh patches.suse/x86-CPU-Add-Icelake-model-number.patch.
- Refresh patches.suse/x86-cpu-sanitize-fam6_atom-naming.patch.
- commit 45e2da6
- perf/x86/intel: Mark expected switch fall-throughs (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/x86-intel-aggregate-big-core-client-naming.patch.
- Refresh
patches.suse/x86-intel-aggregate-big-core-mobile-naming.patch.
- commit ebba1f6
- perf/x86/intel: Fix invalid Bit 13 for Icelake MSR_OFFCORE_RSP_x
register (jsc#PED-5023 bsc#1211439).
- commit b357e8f
- perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge
(jsc#PED-5023 bsc#1211439).
- commit 1e6f0c4
- perf/x86/intel/uncore: Clean up client IMC (jsc#PED-5023
bsc#1211439).
- commit b9f2803
- perf/x86/intel/uncore: Support MMIO type uncore blocks
(jsc#PED-5023 bsc#1211439).
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit 2ed2c09
- perf/x86/intel/uncore: Factor out box ref/unref functions
(jsc#PED-5023 bsc#1211439).
- commit 9298d3b
- perf/x86/intel/uncore: Add uncore support for Snow Ridge server
(jsc#PED-5023 bsc#1211439).
- Refresh
patches.suse/x86-intel-aggregate-big-core-client-naming.patch.
- Refresh
patches.suse/x86-intel-aggregate-big-core-mobile-naming.patch.
- Refresh
patches.suse/x86-intel-aggregate-microserver-naming.patch.
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit 6e7af12
- perf/x86/intel: Add more Icelake CPUIDs (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/x86-intel-aggregate-big-core-client-naming.patch.
- Refresh
patches.suse/x86-intel-aggregate-big-core-mobile-naming.patch.
- commit ba0eb7e
- perf/x86/intel: Add Icelake desktop CPUID (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/intel_rapl-add-support-for-IceLake-desktop.patch.
- Refresh
patches.suse/powercap-intel-rapl-add-support-for-ICX.patch.
- Refresh
patches.suse/x86-intel-aggregate-big-core-client-naming.patch.
- Refresh
patches.suse/x86-intel-aggregate-big-core-mobile-naming.patch.
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit 7786ce1
- perf/x86/intel/uncore: Add new IMC PCI IDs for KabyLake,
AmberLake and WhiskeyLake CPUs (jsc#PED-5023 bsc#1211439).
- commit 4d459ae
- perf/x86/intel/uncore: Add tabs to Uncore IMC PCI IDs
(jsc#PED-5023 bsc#1211439).
- commit 1e8abbc
- perf/x86: Add Intel Ice Lake NNPI uncore support (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/x86-intel-aggregate-big-core-client-naming.patch.
- Refresh
patches.suse/x86-intel-aggregate-big-core-mobile-naming.patch.
- Refresh
patches.suse/x86-perf-events-convert-to-new-cpu-match-macros.patch.
- commit 55befa5
- x86/cpu: Add Ice Lake NNPI to Intel family (jsc#PED-5023
bsc#1211439).
- Refresh
patches.suse/x86-intel-aggregate-big-core-mobile-naming.patch.
- commit 34f99e6
- s390/vx: fix save/restore of fpu kernel context (git-fixes
bsc#1218362).
- commit 657e47b
- nvme: sanitize metadata bounce buffer for reads (git-fixes).
- commit 6f2b20c
- Input: powermate - fix use-after-free in
powermate_config_complete (git-fixes).
- commit 6690cf9
- r8152: Add RTL8152_INACCESSIBLE to r8153_aldps_en() (git-fixes).
- commit 64cb7dc
- ipv4: igmp: fix refcnt uaf issue when receiving igmp query
packet (bsc#1218253 CVE-2023-6932).
- commit ebe786a
- gve: Fixes for napi_poll when budget is 0 (bsc#1214479).
- gve: Do not fully free QPL pages on prefill errors
(bsc#1214479).
- gve: fix frag_list chaining (bsc#1214479).
- gve: RX path for DQO-QPL (bsc#1214479).
- gve: Tx path for DQO-QPL (bsc#1214479).
- gve: Control path for DQO-QPL (bsc#1214479).
- gve: trivial spell fix Recive to Receive (bsc#1214479).
- gve: unify driver name usage (bsc#1214479).
- gve: Set default duplex configuration to full (bsc#1214479).
- gve: Unify duplicate GQ min pkt desc size constants
(bsc#1214479).
- gve: Add XDP REDIRECT support for GQI-QPL format (bsc#1214479).
- gve: Add XDP DROP and TX support for GQI-QPL format
(bsc#1214479).
- gve: Changes to add new TX queues (bsc#1214479).
- gve: XDP support GQI-QPL: helper function changes (bsc#1214479).
- gve: Fix gve interrupt names (bsc#1214479).
- commit 9108d42
- tracing: Update snapshot buffer on resize if it is allocated
(git-fixes).
- commit 30f36d0
- ring-buffer: Fix memory leak of free page (git-fixes).
- commit 7dfbb97
- r8152: Add RTL8152_INACCESSIBLE checks to more loops
(git-fixes).
- commit 6e72146
- net: dsa: mv88e6xxx: Fix 88E6141/6341 2500mbps SERDES speed
(git-fixes).
- commit ce068ed
- r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE
(git-fixes).
- commit 715a8e7
- net: stmmac: Move debugfs init/exit to ->probe()/->remove() (git-fixes).
- commit e003b9a
- net: ethernet: ti: cpsw: unsync mcast entries while switch promisc mode (git-fixes).
- commit 39aa8c8
- net: macb: disable scatter-gather for macb on sama5d3 (git-fixes).
- commit a5f5aa8
- netfilter: nft_compat: use-after-free when deleting targets
(git-fixes).
- commit 2ea1f0c
- netfilter: nf_tables: fix use-after-free when deleting compat
expressions (git-fixes).
- commit b4fa1c0
- tcp: fix under-evaluated ssthresh in TCP Vegas (git-fixes).
- commit b480783
- netfilter: ebtables: also count base chain policies (git-fixes).
- Refresh
patches.kabi/netfilter-preserve-KABI-for-xt_compat_init_offsets.patch.
- commit 051bd2a
- netfilter: ebtables: compat: un-break 32bit setsockopt when
no rules are present (git-fixes).
- Refresh
patches.kabi/netfilter-preserve-KABI-for-xt_compat_init_offsets.patch.
- commit 332123a
- netfilter: ebtables: don't attempt to allocate 0-sized compat
array (git-fixes).
- Refresh
patches.kabi/netfilter-preserve-KABI-for-xt_compat_init_offsets.patch.
- commit 39f9e26
- netfilter: preserve KABI for xt_compat_init_offsets (git-fixes).
- commit 71e46a5
- netfilter: compat: reject huge allocation requests (git-fixes).
- commit f398964
- netfilter: compat: prepare xt_compat_init_offsets to return
errors (git-fixes).
- commit a1a8d4f
- KVM: s390/mm: Properly reset no-dat (git-fixes bsc#1218057).
- commit d3f8ccb
- tracing: Disable snapshot buffer when stopping instance tracers
(git-fixes).
- commit b07eab3
- tracing: Stop current tracer when resizing buffer (git-fixes).
- commit 5c0c11a
- tracing: Always update snapshot buffer size (git-fixes).
- commit c831a81
- tracing: relax trace_event_eval_update() execution with
cond_resched() (git-fixes).
- commit f1e2f19
- xfrm6: fix inet6_dev refcount underflow problem (git-fixes).
- commit 50692e8
- README.BRANCH: update maintainers list
- commit 4795fb8
- ipv6/addrconf: fix a potential refcount underflow for idev
(git-fixes).
- commit 0afb0f6
- ipv6: remove extra dev_hold() for fallback tunnels (git-fixes).
- commit a02e296
- ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods
(git-fixes).
- commit 934530e
- sit: proper dev_{hold|put} in ndo_[un]init methods (git-fixes).
- commit 96165ef
- ip6_vti: proper dev_{hold|put} in ndo_[un]init methods
(git-fixes).
- commit 42264ea
- ip6_gre: proper dev_{hold|put} in ndo_[un]init methods
(git-fixes).
- commit 8fe5105
- xsk: Fix incorrect netdev reference count (git-fixes).
- commit 2ed0c59
- xfrm: reuse uncached_list to track xdsts (git-fixes).
- blacklist.conf: remove from the blacklist
- Refresh
patches.suse/ipv4-fix-race-condition-between-route-lookup-and-inv.patch.
- Refresh
patches.suse/ipv4-lock-mtu-in-fnhe-when-received-PMTU-net.ipv4.ro.patch.
- commit 38edc03
- net/tg3: fix race condition in tg3_reset_task() (bsc#1217801).
- net/tg3: resolve deadlock in tg3_reset_task() during EEH
(bsc#1217801).
- commit b55327d
- tracing: Fix a possible race when disabling buffered events
(bsc#1217036).
- commit 5f21a8d
- net: usb: ax88179_178a: fix failed operations during
ax88179_reset (git-fixes).
- commit 9041dc6
- r8152: Cancel hw_phy_work if we have an error in probe
(git-fixes).
- commit 6ae718a
- r8152: Run the unload routine if we have errors during probe
(git-fixes).
- commit d668b36
- r8152: Increase USB control msg timeout to 5000ms as per spec
(git-fixes).
- commit 3e20995
- tracing: Fix a warning when allocating buffered events fails
(bsc#1217036).
- commit 80b9661
- net: usb: smsc95xx: Fix uninit-value access in smsc95xx_read_reg
(git-fixes).
- net: usb: smsc95xx: Fix an error code in smsc95xx_reset()
(git-fixes).
- commit 9c4175d
- KVM: s390: vsie: fix wrong VIR 37 when MSO is used (git-fixes
bsc#1217936).
- commit 4da118c
- nvmet: nul-terminate the NQNs passed in the connect command
(bsc#1217250 CVE-2023-6121).
- commit 2021a67
- tracing: Fix incomplete locking when disabling buffered events
(bsc#1217036).
- commit 9d8e191
- tracing: Fix warning in trace_buffered_event_disable()
(git-fixes, bsc#1217036).
- commit 693b5e0
- kernel-source: Remove config-options.changes (jsc#PED-5021)
The file doc/config-options.changes was used in the past to document
kernel config changes. It was introduced in 2010 but haven't received
any updates on any branch since 2015. The file is renamed by tar-up.sh
to config-options.changes.txt and shipped in the kernel-source RPM
package under /usr/share/doc. As its content now only contains outdated
information, retaining it can lead to confusion for users encountering
this file.
Config changes are nowadays described in associated Git commit messages,
which get automatically collected and are incorporated into changelogs
of kernel RPM packages.
Drop then this obsolete file, starting with its packaging logic.
For branch maintainers: Upon merging this commit on your branch, please
correspondingly delete the file doc/config-options.changes.
- commit adedbd2
- doc/README.SUSE: Simplify the list of references (jsc#PED-5021)
Reduce indentation in the list of references, make the style consistent
with README.md.
- commit 70e3c33
- doc/README.SUSE: Add how to update the config for module signing
(jsc#PED-5021)
Configuration files for SUSE kernels include settings to integrate with
signing support provided by the Open Build Service. This creates
problems if someone tries to use such a configuration file to build
a "standalone" kernel as described in doc/README.SUSE:
* Default configuration files available in the kernel-source repository
unset CONFIG_MODULE_SIG_ALL to leave module signing to
pesign-obs-integration. In case of a "standalone" build, this
integration is not available and the modules don't get signed.
* The kernel spec file overrides CONFIG_MODULE_SIG_KEY to
".kernel_signing_key.pem" which is a file populated by certificates
provided by OBS but otherwise not available. The value ends up in
/boot/config-$VERSION-$RELEASE-$FLAVOR and /proc/config.gz. If someone
decides to use one of these files as their base configuration then the
build fails with an error because the specified module signing key is
missing.
Add information on how to enable module signing and where to find the
relevant upstream documentation.
- commit a699dc3
- net/ulp: use consistent error code when blocking ULP
(CVE-2023-0461 bsc#1208787 bsc#1217079).
- net/ulp: prevent ULP without clone op from entering the LISTEN
status (CVE-2023-0461 bsc#1208787 bsc#1217079).
- commit fb04b97
- doc/README.SUSE: Remove how to build modules using kernel-source
(jsc#PED-5021)
Remove the first method how to build kernel modules from the readme. It
describes a process consisting of the kernel-source installation,
configuring this kernel and then performing an ad-hoc module build.
This method is not ideal as no modversion data is involved in the
process. It results in a module with no symbol CRCs which can be wrongly
loaded on an incompatible kernel.
Removing the method also simplifies the readme because only two main
methods how to build the modules are then described, either doing an
ad-hoc build using kernel-devel, or creating a proper Kernel Module
Package.
- commit 9285bb8
- Revert "Bluetooth: btsdio: fix use after free bug in
btsdio_remove due to unfinished work" (git-fixes).
- commit a2b7495
- md/raid10: prevent soft lockup while flush writes (git-fixes).
- md/raid10: fix io loss while replacement replace rdev
(git-fixes).
- md/raid10: Do not add spare disk when recovery fails
(git-fixes).
- md/raid10: clean up md_add_new_disk() (git-fixes).
- md/raid10: prioritize adding disk to 'removed' mirror
(git-fixes).
- md/raid10: improve code of mrdev in raid10_sync_request
(git-fixes).
- md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request
(git-fixes).
- md/bitmap: factor out a helper to set timeout (git-fixes).
- md/bitmap: always wake up md_thread in timeout_store
(git-fixes).
- dm-raid: remove useless checking in raid_message() (git-fixes).
- md/raid10: fix wrong setting of max_corr_read_errors
(git-fixes).
- md/raid10: fix overflow of md/safe_mode_delay (git-fixes).
- md: fix data corruption for raid456 when reshape restart while
grow up (git-fixes).
- md/raid10: check slab-out-of-bounds in md_bitmap_get_counter
(git-fixes).
- md/raid10: fix memleak of md thread (git-fixes).
- md/raid10: fix memleak for 'conf->bio_split' (git-fixes).
- md/raid10: fix leak of 'r10bio->remaining' for recovery
(git-fixes).
- md/raid10: fix null-ptr-deref in raid10_sync_request
(git-fixes).
- md: avoid signed overflow in slot_store() (git-fixes).
- md: fix incorrect declaration about claim_rdev in
md_import_device (git-fixes).
- md: remove lock_bdev / unlock_bdev (git-fixes).
- md: Flush workqueue md_rdev_misc_wq in md_alloc() (git-fixes).
- md: do not return existing mddevs from mddev_find_or_alloc
(git-fixes).
- md: refactor mddev_find_or_alloc (git-fixes).
- md: factor out a mddev_alloc_unit helper from mddev_find
(git-fixes).
- md: get sysfs entry after redundancy attr group create
(git-fixes).
- commit 293695f
- md: fix deadlock causing by sysfs_notify (git-fixes).
- Refresh patches.kabi/md-backport-kabi.patch.
- commit f6c5a12
- md: flush md_rdev_misc_wq for HOT_ADD_DISK case (git-fixes).
- md: add new workqueue for delete rdev (git-fixes).
- commit 17e8908
- usb-storage: fix deadlock when a scsi command timeouts more
than once (git-fixes).
- commit cf05cec
- USB: serial: option: add UNISOC vendor and TOZED LT70C product
(git-fixes).
- commit 762e0de
- USB: serial: option: add Quectel RM500U-CN modem (git-fixes).
- Refresh
patches.suse/USB-serial-option-add-Quectel-EC200A-module-support.patch.
- commit b94685a
- USB: serial: option: add Telit FE990 compositions (git-fixes).
- commit 55c3b8d
- usb: typec: tcpm: Fix altmode re-registration causes sysfs
create fail (git-fixes).
- commit fc9ee7b
- net: mana: Configure hwc timeout from hardware (bsc#1214037).
- net: mana: Fix MANA VF unload when hardware is unresponsive
(bsc#1214764).
- commit 66a91f5
- Update patches.kabi/NFSv4-Fix-OPEN-CLOSE-race-FIX.patch
(bsc#1176950, bsc#1217525).
- Refresh
patches.kabi/NFSv4-Wait-for-stateid-updates-after-CLOSE-OPEN_DOWN_kabi.patch.
- commit 70e60bf
- netfilter: conntrack: dccp: copy entire header to stack buffer,
not just basic one (CVE-2023-39197 bsc#1216976).
- commit 91c26b6
- kernel-binary: suse-module-tools is also required when installed
Requires(pre) adds dependency for the specific sciptlet.
However, suse-module-tools also ships modprobe.d files which may be
needed at posttrans time or any time the kernel is on the system for
generating ramdisk. Add plain Requires as well.
- commit 8c12816
- rpm: Use run_if_exists for all external scriptlets
With that the scriptlets do not need to be installed for build.
- commit 25edd65
- ext4: Avoid freeing inodes on dirty list (bsc#1216989).
- commit 44d936e
- Revert "tracing: Fix warning in trace_buffered_event_disable()"
(bsc#1217036)
Temporarily revert the commit. It exposed a separate issue related to
trace buffered event synchronization which needs to be fixed first.
- commit 579dd1d
- README.SUSE: fix patches.addon use
It's series, not series.conf in there.
And make it more precise on when the patches are applied.
- commit cb8969c
- Do not store build host name in initrd
Without this patch, kernel-obs-build stored the build host name
in its .build.initrd.kvm
This patch allows for reproducible builds of kernel-obs-build and thus
avoids re-publishing the kernel-obs-build.rpm when nothing changed.
Note that this has no influence on the /etc/hosts file
that is used during other OBS builds.
https://bugzilla.opensuse.org/show_bug.cgi?id=1084909
- commit fd3a75e
- cpu/hotplug: Create SMT sysfs interface for all arches
(bsc#1214285 bsc#1205462 ltc#200161 ltc#200588).
- Refresh patches.suse/cpu-SMT-Move-SMT-prototypes-into-cpu_smt.h.patch.
- Refresh patches.suse/cpu-SMT-Store-the-current-max-number-of-threads.patch.
- Refresh patches.suse/cpu-smt-create-and-export-cpu_smt_possible.patch.
- Refresh patches.suse/x86-power-Fix-nosmt-vs-hibernation-triple-fault-duri.patch.
- commit f37a0c7
- Update config files.
- commit dbf7641
- s390/cio: unregister device when the only path is gone
(git-fixes bsc#1217607).
- commit 750467a
- s390/dasd: use correct number of retries for ERP requests
(git-fixes bsc#1217604).
- s390/ptrace: fix PTRACE_GET_LAST_BREAK error handling (git-fixes
bsc#1217603).
- commit d2fc41b
- cpu/SMT: Remove topology_smt_supported() (bsc#1214408).
- commit 3012e9b
- cpu/SMT: Store the current/max number of threads (bsc#1214408).
- Refresh
patches.kabi/cpu-hotplug-Fix-SMT-disabled-by-BIOS-detection-for-K.patch.
- commit bfa1761
- cpu/SMT: Move smt/control simple exit cases earlier (bsc#1214408).
- commit acb1c39
- cpu/SMT: Move SMT prototypes into cpu_smt.h (bsc#1214408).
- Refresh
patches.kabi/cpu-hotplug-Fix-SMT-disabled-by-BIOS-detection-for-K.patch.
- commit 76bedc5
- s390/dasd: protect device queue against concurrent access
(git-fixes bsc#1217519).
- commit dab3b0f
- tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and
docker together (bsc#1216031).
- commit f260538
- Ensure ia32_emulation is always enabled for kernel-obs-build
If ia32_emulation is disabled by default, ensure it is enabled
back for OBS kernel to allow building 32bit binaries (jsc#PED-3184)
[ms: Always pass the parameter, no need to grep through the config which
may not be very reliable]
- commit 56a2c2f
- rpm: Define git commit as macro
- commit bcc92c8
- kernel-source: Move provides after sources
- commit dbbf742
- kobject: Fix slab-out-of-bounds in fill_kobj_path() (bsc#1216058
CVE-2023-45863).
- commit 9922921
- xfs: make sure maxlen is still congruent with prod when rounding
down (git-fixes).
- commit 0154927
- xfs: fix units conversion error in xfs_bmap_del_extent_delay
(git-fixes).
- commit 6c99467
- l2tp: fix refcount leakage on PPPoL2TP sockets (git-fixes).
- commit 0e54c67
- l2tp: fix {pppol2tp, l2tp_dfs}_seq_stop() in case of seq_file
overflow (git-fixes).
- commit 28faea4
- perf/core: Fix potential NULL deref (bsc#1216584 CVE-2023-5717).
- commit f386e74
- perf: Disallow mis-matched inherited group reads (bsc#1216584 CVE-2023-5717).
Implement KABI fix for above
- commit 5b65c0e
- perf/core: Fix __perf_read_group_add() locking (bsc#1216584
CVE-2023-5717).
- perf/core: Fix locking for children siblings group read
(bsc#1216584 CVE-2023-5717).
- commit 8ccfe6e
- s390/crashdump: fix TOD programmable field size (git-fixes
bsc#1217206).
- commit 9780bde
- ring-buffer: Avoid softlockup in ring_buffer_resize()
(git-fixes).
- commit d8d3409
- scsi: qla2xxx: Use FIELD_GET() to extract PCIe capability fields
(git-fixes).
- scsi: qla2xxx: Fix double free of dsd_list during driver load
(git-fixes).
- commit 9172a73
- rpm/check-for-config-changes: add HAVE_SHADOW_CALL_STACK to IGNORED_CONFIGS_RE
Not supported by our compiler.
- commit eb32b5a
- s390/cmma: fix handling of swapper_pg_dir and invalid_pg_dir
(LTC#203996 bsc#1217087).
- commit 3a41a21
- s390/cmma: fix detection of DAT pages (LTC#203996 bsc#1217087).
- commit b4ffc60
- s390/mm: add missing arch_set_page_dat() call to gmap
allocations (LTC#203996 bsc#1217087).
- commit 1b2cc83
- s390/mm: add missing arch_set_page_dat() call to
vmem_crst_alloc() (LTC#203996 bsc#1217087).
- commit 0dd665d
- s390/cmma: fix initial kernel address space page table walk
(LTC#203996 bsc#1217087).
- commit 1ad76c2
- igb: set max size RX buffer when store bad packet is enabled
(bsc#1216259 CVE-2023-45871).
- commit d675d77
- drm/qxl: fix UAF on handle creation (CVE-2023-39198
bsc#1216965).
- commit 9ba677b
- Bluetooth: hci_ldisc: check HCI_UART_PROTO_READY flag in
HCIUARTGETPROTO (bsc#1210780 CVE-2023-31083).
- commit b07c667
- rpm/check-for-config-changes: add AS_WRUSS to IGNORED_CONFIGS_RE
Add AS_WRUSS as an IGNORED_CONFIGS_RE entry in check-for-config-changes
to fix build on x86_32.
There was a fix submitted to upstream but it was not accepted:
https://lore.kernel.org/all/20231031140504.GCZUEJkMPXSrEDh3MA@fat_crate.local/
So carry this in IGNORED_CONFIGS_RE instead.
- commit 7acca37
- net-memcg: Fix scope of sockmem pressure indicators
(bsc#1216759).
- commit 508863b
- ubi: Refuse attaching if mtd's erasesize is 0 (CVE-2023-31085
bsc#1210778).
- commit 0f8804e
- USB: ene_usb6250: Allocate enough memory for full object
(bsc#1216051 CVE-2023-45862).
- commit 6d3e018
- scsi: zfcp: Fix a double put in zfcp_port_enqueue() (git-fixes
bsc#1216514).
- commit 64da298
- s390/pci: fix iommu bitmap allocation (git-fixes bsc#1216513).
- commit 5844864
- sched/fair: Don't balance task to its current running CPU
(git fixes (sched)).
- sched/core: Mitigate race
cpus_share_cache()/update_top_cache_domain() (git fixes
(sched)).
- sched: Reenable interrupts in do_sched_yield() (git fixes
(sched)).
- sched: correct SD_flags returned by tl->sd_flags() (git fixes
(sched)).
- sched: Avoid scale real weight down to zero (git fixes (sched)).
- sched/core: Fix migration to invalid CPU in
__set_cpus_allowed_ptr() (git fixes (sched)).
- sched/rt: Restore rt_runtime after disabling RT_RUNTIME_SHARE
(git fixes (sched)).
- sched/rt: Minimize rq->lock contention in
do_sched_rt_period_timer() (git fixes (sched)).
- commit 913e5fc
- iommu/amd: Set iommu->int_enabled consistently when interrupts
are set up (bsc#1206010).
- commit d889c94
- iommu/amd: Remove useless irq affinity notifier (bsc#1206010).
- Delete patches.kabi/kABI-Fix-kABI-for-struct-amd_iommu.patch.
- commit 2e08e52
- kabi: iommu/amd: Fix IOMMU interrupt generation in X2APIC mode
(bsc#1206010).
- iommu/amd: Fix IOMMU interrupt generation in X2APIC mode
(bsc#1206010).
- commit 422a4d8
- virtio_balloon: fix increment of vb->num_pfns in fill_balloon()
(git-fixes).
- commit 595e0b1
- 9p: virtio: make sure 'offs' is initialized in zc_request
(git-fixes).
- commit 10bf215
- virtio_net: Fix error unwinding of XDP initialization
(git-fixes).
- commit 2d8db2e
- vhost-scsi: unbreak any layout for response (git-fixes).
- commit 4eba973
- virtio: Protect vqs list access (git-fixes).
- commit 0445801
- crypto: virtio: Fix use-after-free in
virtio_crypto_skcipher_finalize_req() (git-fixes).
- commit 1c1619c
- vsock/virtio: add transport parameter to the
virtio_transport_reset_no_sock() (git-fixes).
- Refresh
patches.suse/vhost-vsock-accept-only-packets-with-the-right-dst_c.patch.
patches.suse/net-virtio_vsock-Enhance-connection-semantics.patch
- commit b2f8fd4
- virtio_balloon: fix deadlock on OOM (git-fixes).
- commit 55dd88a
- xen-netback: use default TX queue size for vifs (git-fixes).
- commit bcb62a2
- xen/x86: obtain full video frame buffer address for Dom0 also
under EFI (bsc#1215743).
- commit 04d5576
- xen/x86: obtain upper 32 bits of video frame buffer address
for Dom0 (bsc#1215743).
- commit e0fb7ee
- s390/ptrace: fix setting syscall number (git-fixes bsc#1216340).
- commit 46941f7
- usb: typec: altmodes/displayport: fix pin_assignment_show
(git-fixes).
- commit d110fbf
- usb: typec: altmodes/displayport: Fix configure initial pin
assignment (git-fixes).
- commit 849955e
- net: usb: dm9601: fix uninitialized variable use in
dm9601_mdio_read (git-fixes).
- commit f96b2d4
- xen/events: replace evtchn_rwlock with RCU (bsc#1215745,
xsa-441, cve-2023-34324).
- commit a9545c4
- s390/vdso: add missing FORCE to build targets (git-fixes
bsc#1216140).
- commit cd866ae
- ratelimit: Fix data-races in ___ratelimit() (git-fixes).
- commit 3f2541c
- audit: fix potential double free on error path from
fsnotify_add_inode_mark (git-fixes).
- commit 4086838
- tools/thermal: Fix possible path truncations (git-fixes).
- commit 012a1c3
- KVM: s390: fix sthyi error handling (git-fixes bsc#1216107).
- commit 1e42611
- netfilter: nfnetlink_osf: avoid OOB read (bsc#1216046
CVE-2023-39189).
- commit 1a88b87
- kabi: blkcg_policy_data fix KABI (bsc#1216062 bsc#1225203).
- commit 6c1e81e
- blk-cgroup: support to track if policy is online (bsc#1216062 bsc#1225203).
- commit c56f565
- mm, memcg: reconsider kmem.limit_in_bytes deprecation
(bsc#1208788 bsc#1213705).
- commit 2d13fe0
- memcg: drop kmem.limit_in_bytes (bsc#1208788)
This brings a breaking commit for easier backport, it'll be fixed
differently in a following commit.
- commit f87e772
- blk-cgroup: Fix NULL deref caused by blkg_policy_data being
installed before init (bsc#1216062 bsc#1225203).
- commit 0dd445b
- USB: serial: cp210x: add Silicon Labs IFS-USB-DATACABLE IDs
(git-fixes).
- commit 86ad453
- uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2
(git-fixes).
- commit 5c6ec60
- net: usb: smsc75xx: Fix uninit-value access in
__smsc75xx_read_reg (git-fixes).
- commit aaff955
- mkspec-dtb: add toplevel symlinks also on arm
- commit ed29cae
- doc/README.PATCH-POLICY.SUSE: Convert the document to Markdown
(jsc#PED-5021)
- commit c05cfc9
- doc/README.SUSE: Convert the document to Markdown (jsc#PED-5021)
- commit bff5e3e
- ring-buffer: Fix bytes info in per_cpu buffer stats (git-fixes).
- commit 5490bdd
- tracing: Fix race issue between cpu buffer write and swap
(git-fixes).
- commit cd23ed9
- tracing: Fix memleak due to race between current_tracer and
trace (git-fixes).
- commit 39d6a56
- tracing: Fix cpu buffers unavailable due to 'record_disabled'
missed (git-fixes).
- commit 6f0b300
- Update
patches.suse/ipv6-sr-fix-out-of-bounds-read-when-setting-HMAC-dat.patch
(bsc#1211592 CVE-2023-2860).
- commit bb891c5
- s390/zcrypt: fix reply buffer calculations for CCA replies
(LTC#203322 bsc#1213950).
- commit 877301e
- s390/zcrypt: change reply buffer size offering (LTC#203322
bsc#1213950).
- commit e230ae5
- scsi: zfcp: Defer fc_rport blocking until after ADISC response
(LTC#203327 bsc#1213977 git-fixes).
- commit 1163975
Package python was updated:
- Add CVE-2025-13836-http-resp-cont-len.patch (bsc#1254400, CVE-2025-13836) to prevent reading an HTTP response from
a server, if no read amount is specified, with using
Content-Length per default as the length.
- Add CVE-2025-12084-minidom-quad-search.patch prevent quadratic
behavior in node ID cache clearing (CVE-2025-12084,
bsc#1254997).
- Add CVE-2025-8291-consistency-zip64.patch which checks
consistency of the zip64 end of central directory record, and
preventing obfuscation of the payload, i.e., you scanning for
malicious content in a ZIP file with one ZIP parser (let's say
a Rust one) then unpack it in production with another (e.g.,
the Python one) and get malicious content that the other parser
did not see (CVE-2025-8291, bsc#1251305)
- Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now
validates archives to ensure member offsets are non-negative
(gh#python/cpython#130577, CVE-2025-8194, bsc#1247249).
- Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst
case quadratic complexity when processing certain crafted
malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705).
- Update CVE-2024-11168-validation-IPv6-addrs.patch
according modifications by the Debian
developers (Sylvain Beucler <beuc@debian.org>,
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)
- Add CVE-2024-11168-validation-IPv6-addrs.patch
fixing bsc#1233307 (CVE-2024-11168,
gh#python/cpython#103848): Improper validation of IPv6 and
IPvFuture addresses.
- Add ipaddress module from https://github.com/phihag/ipaddress
- Remove -IVendor/ from python-config boo#1231795
- Stop using %%defattr, it seems to be breaking proper executable
attributes on /usr/bin/ scripts (bsc#1227378).
- bsc#1221854 (CVE-2024-0450) Add
CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
detecting the vulnerability of the "quoted-overlap" zipbomb
(from gh#python/cpython!110016).
- Switch to using the system libexpat (bsc#1219559,
CVE-2023-52425)
- Make sure to remove all embedded versions of other packages
(including expat).
- Add CVE-2023-52425-libexpat-2.6.0-remove-failing-tests.patch
removing failing test fixing bpo#3151, which we just not
support.
- Remove patches over those embedded packages (cffi):
- python-2.7-libffi-aarch64.patch
- sparc_longdouble.patch
- Modify CVE-2023-27043-email-parsing-errors.patch to fix the
unicode string handling in email.utils.parseaddr()
(bsc#1222537).
- Revert CVE-2022-48560-after-free-heappushpop.patch, the fix was
unneeded.
- Switch off tests. ONLY FOR FACTORY!!! (bsc#1219306)
- Build with -std=gnu89 to build correctly with gcc14, bsc#1220970
- Add CVE-2023-27043-email-parsing-errors.patch to
gh#python/cpython!111116, fixing bsc#1210638 (CVE-2023-27043).
- Add CVE-2022-48560-after-free-heappushpop.patch fixing
use-after-free in Python via heappushpop in heapq (bsc#1214675,
CVE-2022-48560).
- switch from %patchN style to the %patch -P N one.
Package ncurses was updated:
- Add patch ncurses-5.9-bsc1220061.patch (bsc#1220061, CVE-2023-45918) * Backport from ncurses-6.4-20230615.patch
improve checks in convert_string() for corrupt terminfo entry
- Add patch bsc1218014-cve-2023-50495.patch
* Fix CVE-2023-50495: segmentation fault via _nc_wrap_entry()
(bsc#1218014)
- Add patch bsc1218014-cve-2023-50495.patch
* Fix CVE-2023-50495: segmentation fault via _nc_wrap_entry()
Package supportutils was updated:
- Changes in version 3.0.12 + Optimize lsof usage (bsc#1183663)
+ Collects ntp or chrony as needed (bsc#1196293)
- Added email.txt based on OPTION_EMAIL
- Added run time detection (bsc#1213127)
Package openldap2 was updated:
- bsc#1217985 - Null pointer deref in referrals as part of ldap_chain_response()
* 0229-ITS-9262-check-referral.patch
- bsc#1220787 - increase DH param minimums to 2048 bits
* 0228-bsc-1220787-increase-dh-param-minimums.patch
Package python3 was updated:
- Readjust CVE-2025-4435-normalize-lnk-trgts-tarfile.patch on the top of the previous patch. Security fixes for CVE-2025-4517,
CVE-2025-4330, CVE-2025-4138, CVE-2024-12718, CVE-2025-4435 on
tarfile (bsc#1244032, bsc#1244061, bsc#1244059, bsc#1244060,
bsc#1244056). The backported fixes do not contain changes for
ntpath.py and related tests, because the support for symlinks
and junctions were added later in Python 3.9, and it does not
make sense to backport them to 3.6 here. The patch is contains
the following changes:
- python@42deeab fixes symlink handling for tarfile.data_filter
- python@9d2c2a8 fixes handling of existing files/symlinks in
tarfile
- python@00af979 adds a new "strict" argument to realpath()
- python@dd8f187 fixes mulriple CVE fixes in the tarfile module
- downstream only fixes that makes the changes work and
compatible with Python 3.6
- Readjust CVE-2025-8194-tarfile-no-neg-offsets.patch on the top
of the previous two patches
- Add remove-usr-local-bin-shebangs.patch for removing two
shebangs with /usr/local/bin/python (with the complexity of the
current patchset fiddling with the files with `sed` makes those
patches unmaintainable).
- Finally ported CVE-2007-4559-filter-tarfile_extractall.patch
for Python 3.4 (CVE-2007-4559, bsc#1203750, bsc#1251841).
- Add CVE-2025-13836-http-resp-cont-len.patch (bsc#1254400,
CVE-2025-13836) to prevent reading an HTTP response from
a server, if no read amount is specified, with using
Content-Length per default as the length.
- Add CVE-2025-12084-minidom-quad-search.patch prevent quadratic
behavior in node ID cache clearing (CVE-2025-12084,
bsc#1254997).
- Add CVE-2025-13837-plistlib-mailicious-length.patch protect
against OOM when loading malicious content (CVE-2025-13837,
bsc#1254401).
- Fix the build system with two patches:
- spc-tab-Makefile-pre-in.patch there are space-indended lines
in the Makefile.pre.in in tarball (!!!), fix that
- Modules_Setup.patch, Modules/makesetup script is kind of
broken (gh#python/cpython!4338 among others)
- time-static.patch make time module statically built into the
interpreter
- Add s390-build.patch to skip failing test on s390.
- Add CVE-2025-6075-expandvars-perf-degrad.patch avoid simple
quadratic complexity vulnerabilities of os.path.expandvars()
(CVE-2025-6075, bsc#1252974).
- Add also two small patches:
- lchmod-non-support.patch adding @requires_lchmod operator
for skipping tests on platforms were changing the mode of
symbolic links is supported (which it isnât in SLE-12,
apparently).
- locale-test_float_with_commad.patch for decoding byte strings
in localeconv() for consistent output
- Update pip wheel to pip-20.2.3-py2.py3-none-any.whl.
- Add CVE-2025-8291-consistency-zip64.patch which checks
consistency of the zip64 end of central directory record, and
preventing obfuscation of the payload, i.e., you scanning for
malicious content in a ZIP file with one ZIP parser (let's say
a Rust one) then unpack it in production with another (e.g.,
the Python one) and get malicious content that the other parser
did not see (CVE-2025-8291, bsc#1251305)
- Readjust patches while synchronizing between openSUSE and SLE trees:
- 99366-patch.dict-can-decorate-async.patch
- CVE-2007-4559-filter-tarfile_extractall.patch
- CVE-2020-10735-DoS-no-limit-int-size.patch
- CVE-2024-6232-ReDOS-backtrack-tarfile.patch
- CVE-2025-4435-normalize-lnk-trgts-tarfile.patch
- CVE-2025-8194-tarfile-no-neg-offsets.patch
- python-3.6.0-multilib-new.patch
- python3-sorted_tar.patch
- Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now
validates archives to ensure member offsets are non-negative
(gh#python/cpython#130577, CVE-2025-8194, bsc#1247249).
- Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst
case quadratic complexity when processing certain crafted
malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705).
- Add functools-cached_property.patch adding the port of
functools.cached_property from Python 3.8
- Add ipaddress-update-pr60.patch from gh#phihag/ipaddress!60 to
update vendored ipaddress module to 3.8 equivalent
- Add gh-128840_parse-IPv6-with-emb-IPv4.patch to limit buffer
size for IPv6 address parsing (gh#python/cpython#128840,
bsc#1244401).
- Make the time module statically linked to prevent faliure to
start when building.
- Update CVE-2024-11168-validation-IPv6-addrs.patch
according to the Debian version
(gh#python/cpython#103848#issuecomment-2708135083).
- Remove python-3.3.0b1-test-posix_fadvise.patch (not needed
since kernel 3.6-rc1)
- 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)
- Remove -IVendor/ from python-config boo#1231795
- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1
- Add CVE-2024-11168-validation-IPv6-addrs.patch
fixing bsc#1233307 (CVE-2024-11168,
gh#python/cpython#103848): Improper validation of IPv6 and
IPvFuture addresses.
- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
path names provided when creating a virtual environment
(bsc#1232241, CVE-2024-9287)
- Drop .pyc files from docdir for reproducible builds
(bsc#1230906).
- Add CVE-2024-7592-quad-complex-cookies.patch (bsc#1229596,
CVE-2024-7592), which fixes quadratic complexity in parsing
"-quoted cookie values with backslashes by http.cookies.
- Add CVE-2024-6232-ReDOS-backtrack-tarfile.patch prevent
ReDos via excessive backtracking while parsing header values
(bsc#1230227, CVE-2024-6232).
- Add bpo27240-rewrite_email_hdr_fold.patch rewriting the email
header folding algorithm to make the codebase compatible with
Python 3.6.4+, so we can continue to maintain it.
- And even before that we have to add
bpo24211-RFC6532-supp-email.patch.
- Also bpo20098-email-mangle_from-policy.patch.
- Add finally, CVE-2024-6923-email-hdr-inject.patch to prevent
email header injection due to unquoted newlines (bsc#1228780,
CVE-2024-6923).
- Add CVE-2024-4032-private-IP-addrs.patch to fix bsc#1226448
(CVE-2024-4032) rearranging definition of private v global IP
addresses.
- Stop using %%defattr, it seems to be breaking proper executable
attributes on /usr/bin/ scripts (bsc#1227378).
- bsc#1221854 (CVE-2024-0450) Add
CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
detecting the vulnerability of the "quoted-overlap" zipbomb
(from gh#python/cpython!110016).
- Add CVE-2023-52425-libexpat-2.6.0-backport.patch fixing etree
XMLPullParser tests for Expat >=2.6.0 with reparse deferral
(fixing CVE-2023-52425 or bsc#1219559).
- Add CVE-2023-40217-avoid-ssl-pre-close.patch fixing
gh#python/cpython#108310, backport from upstream patch
gh#python/cpython#108315
(bsc#1214692, CVE-2023-40217)
- (bsc#1219666, CVE-2023-6597) Add
CVE-2023-6597-TempDir-cleaning-symlink.patch (patch from
gh#python/cpython!99930) fixing symlink bug in cleanup of
tempfile.TemporaryDirectory.
- Repurpose skip-failing-tests.patch to increase timeout for
test.test_asyncio.test_tasks.TimeoutTests.test_timeout_time,
which fails on slow machines in IBS (s390x).
- Refresh CVE-2023-27043-email-parsing-errors.patch from
gh#python/cpython!111116, fixing bsc#1210638 (CVE-2023-27043).
Package sudo was updated:
- Fix a possilbe local privilege escalation via the --host option [bsc#1245274, CVE-2025-32462]
- Fix a regression in -P handling cased by fix for CVE-2021-3156
Fix provided by Brahmajit Das [bsc#1234371]
* sudo-CVE-2021-3156.patch updated
- Fix NOPASSWD issue introduced by patches for CVE-2023-42465
[bsc#1221151, bsc#1221134]
* Update sudo-CVE-2023-42465-1of2.patch sudo-CVE-2023-42465-2of2.patch
* Enable running regression selftests during build time.
- Security fix: [bsc#1219026, bsc#1220389, CVE-2023-42465]
* Try to make sudo less vulnerable to ROWHAMMER attacks.
* Add sudo-CVE-2023-42465-1of2.patch sudo-CVE-2023-42465-2of2.patch
Package screen was updated:
- also use tty fd passing after a suspend (MSG_CONT) new patch: sendfdcont.diff
- do not chmod the tty for multiattach, rely on tty fd passing
instead [bsc#1242269] [CVE-2025-46802]
new patch: nottychmod.diff
Package util-linux-systemd was updated:
- agetty: Prevent login cursor escape (bsc#1194818, util-linux-agetty-prevent-cursor-escape.patch).
- Don't delete binaries not common for all architectures. Create an
util-linux-extra subpackage instead, so users of third party
tools can use them. (bsc#1222285)
- fix Xen virtualization type misidentification bsc#1215918
lscpu-fix-parameter-order-for-ul_prefix_fopen.patch
- Properly neutralize escape sequences in wall
(util-linux-CVE-2024-28085.patch, bsc#1221831, CVE-2024-28085,
and its prerequisites: util-linux-fputs_careful1.patch,
util-linux-wall-migrate-to-memstream.patch
util-linux-fputs_careful2.patch).
Package ruby2.1 was updated:
- Add CVE-2024-47220.patch (CVE-2024-47220) Fix HTTP request smuggling (boo#1230930)
Package cups was updated:
- cups-1.7.5-CVE-2025-61915.patch is based on https://github.com/OpenPrinting/cups-ghsa-hxm8-vfpq-jrfc/pull/2
backported to CUPS 1.7.5 to fix CVE-2025-61915
"Local denial-of-service via cupsd.conf update
and related issues"
https://github.com/OpenPrinting/cups/security/advisories/GHSA-hxm8-vfpq-jrfc
bsc#1253783
- In general regarding CUPS security issues and/or DoS issues see
https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings
- cups-1.7.5-CVE-2025-58364.patch is derived
from the upstream patch to fix CVE-2025-58364
"Remote DoS via null dereference"
https://github.com/OpenPrinting/cups/security/advisories/GHSA-7qx3-r744-6qv4
bsc#1249128
- cups-1.7.5-CVE-2025-58060.patch is derived
from the upstream patch against CUPS 2.4
to fix CVE-2025-58060
"Authentication bypass with AuthType Negotiate"
https://github.com/OpenPrinting/cups/security/advisories/GHSA-4c68-qgrh-rmmq
bsc#1249049
- cups-1.7.5-CVE-2024-35235.patch for CUPS 1.7.5 in SLE12
is derived from our cups-2.2.7-CVE-2024-35235.patch for SLE15
which was derived from the upstream patch for CUPS 2.5
to behave backward compatible for CUPS 1.7.5 in SLE12
to fix CVE-2024-35235
"cupsd Listen port arbitrary chmod 0140777"
without the more secure but backward-incompatible behaviour
of the upstream patch for CUPS 2.5
that ignores domain sockets specified in 'Listen' entries
in /etc/cups/cupsd.conf when cupsd is lauched via systemd
(in particular when launched on-demand by systemd)
https://github.com/OpenPrinting/cups/security/advisories/GHSA-vvwp-mv6j-hw6f
bsc#1225365
Package bind was updated:
- Security Fixes: * Address various spoofing attacks.
[CVE-2025-40778, bsc#1252379, bind-9.11-CVE-2025-40778.patch]
- 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]
- Security Fixes:
* It is possible to craft excessively large numbers of resource
record types for a given owner name, which has the effect of
slowing down database processing. This has been addressed by
only allowing a maximum of 100 records to be stored per name
and type in a cache or zone database.
(CVE-2024-1737)
[bsc#1228256, bind-9.11-CVE-2024-1737.patch]
* Validating DNS messages signed using the SIG(0) protocol (RFC
2931) could cause excessive CPU load, leading to a
denial-of-service condition. Support for SIG(0) message
validation was removed from this version of named.
(CVE-2024-1975)
[bsc#1228257, bind-9.11-CVE-2024-1975.patch]
- Security Fixes:
* Validating DNS messages containing a lot of DNSSEC signatures
could cause excessive CPU load, leading to a denial-of-service
condition. This has been fixed. (CVE-2023-50387)
[bsc#1219823, bind-CVE-2023-50387-CVE-2023-50868.patch]
* Preparing an NSEC3 closest encloser proof could cause excessiv
CPU load, leading to a denial-of-service condition. This has
been fixed. (CVE-2023-50868)
[bsc#1219826, bind-CVE-2023-50387-CVE-2023-50868.patch]
* Parsing DNS messages with many different names could cause
excessive CPU load. This has been fixed. (CVE-2023-4408)
[bsc#1219851, bind-CVE-2023-4408.patch]
Package python3-requests was updated:
- Add CVE-2024-47081.patch upstream patch, fixes netrc credential leak (gh#psf/requests#6965, CVE-2024-47081, bsc#1244039)
Package kbd was updated:
- Don't search for resources in the current directory. It can cause unwanted side effects or even infinite loop (bsc#1237230,
kbd-ignore-working-directory-1.patch,
kbd-ignore-working-directory-2.patch,
kbd-ignore-working-directory-3.patch).
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-v20260125-x86-64/
Public Cloud Image Info
https://www.suse.com/support/security/rating/
SUSE Security Ratings
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
augeas-1.10.1-4.6.1
augeas-lenses-1.10.1-4.6.1
autofs-5.1.3-3.17.1
bash-4.3-83.36.1
bind-utils-9.11.22-3.65.1
ca-certificates-1_201403302107-15.9.1
ca-certificates-mozilla-2.74-12.51.1
cloud-netconfig-gce-1.14-35.1
cloud-regionsrv-client-10.5.2-52.132.1
cloud-regionsrv-client-plugin-gce-1.0.0-52.132.1
coreutils-8.25-13.19.1
cpio-2.11-36.21.1
cups-libs-1.7.5-20.57.1
curl-8.0.1-11.114.1
cyrus-sasl-2.1.26-14.7.9
cyrus-sasl-digestmd5-2.1.26-14.7.9
cyrus-sasl-gssapi-2.1.26-14.7.9
cyrus-sasl-plain-2.1.26-14.7.9
cyrus-sasl-saslauthd-2.1.26-14.7.8
expat-2.7.1-21.46.1
fdupes-1.61-8.3.1
glib2-tools-2.48.2-12.55.1
glibc-2.22-114.40.1
glibc-i18ndata-2.22-114.40.1
glibc-locale-2.22-114.40.1
google-guest-agent-20250506.01-1.53.1
google-guest-configs-20241205.00-1.43.1
google-guest-oslogin-20240311.00-1.40.1
google-osconfig-agent-20250416.02-1.41.1
grep-2.16-4.9.1
grub2-2.02-193.1
grub2-i386-pc-2.02-193.1
grub2-x86_64-efi-2.02-193.1
iputils-s20161105-11.12.1
kbd-2.0.4-8.13.1
kbd-legacy-2.0.4-8.13.1
kernel-default-4.12.14-122.283.1
krb5-1.16.3-46.21.1
krb5-client-1.16.3-46.21.1
ksh-93vu-19.3.2
less-458-7.15.1
libX11-6-1.6.2-12.36.1
libX11-data-1.6.2-12.36.1
libapparmor1-2.8.2-56.26.1
libaugeas0-1.10.1-4.6.1
libavahi-client3-0.6.32-32.33.1
libavahi-common3-0.6.32-32.33.1
libbind9-161-9.11.22-3.65.1
libblkid1-2.33.2-4.45.2
libcurl4-8.0.1-11.114.1
libdb-4_8-4.8.30-38.2
libdns1110-9.11.22-3.65.1
libexpat1-2.7.1-21.46.1
libfastjson4-0.99.8-3.6.1
libfdisk1-2.33.2-4.45.2
libfreetype6-2.6.3-7.24.1
libgcc_s1-13.3.0+git8781-1.16.1
libgcrypt20-1.6.1-16.86.1
libgio-2_0-0-2.48.2-12.55.1
libglib-2_0-0-2.48.2-12.55.1
libgmodule-2_0-0-2.48.2-12.55.1
libgnutls30-3.4.17-8.20.1
libgobject-2_0-0-2.48.2-12.55.1
libicu52_1-52.1-8.16.1
libicu52_1-data-52.1-8.16.1
libirs161-9.11.22-3.65.1
libisc1107-9.11.22-3.65.1
libisccc161-9.11.22-3.65.1
libisccfg163-9.11.22-3.65.1
libldap-2_4-2-2.4.41-22.26.9
liblwres161-9.11.22-3.65.1
libmount1-2.33.2-4.45.2
libncurses5-5.9-88.1
libncurses6-5.9-88.1
libnghttp2-14-1.39.2-3.18.1
libopenssl1_0_0-1.0.2p-3.98.1
libopenssl1_1-1.1.1d-2.119.1
libpcap1-1.8.1-10.9.1
libpci3-3.5.6-11.12.1
libpng16-16-1.6.8-15.15.1
libpolkit0-0.113-5.30.1
libprocps3-3.3.9-11.33.1
libpython2_7-1_0-2.7.18-33.56.1
libpython3_4m1_0-3.4.10-25.169.1
libpython3_6m1_0-3.6.15-97.1
libreadline6-6.3-83.36.1
libruby2_1-2_1-2.1.9-19.9.1
libsasl2-3-2.1.26-14.7.9
libseccomp2-2.5.3-11.9.1
libsmartcols1-2.33.2-4.45.2
libsqlite3-0-3.50.2-9.41.1
libssh4-0.9.8-3.18.1
libstdc++6-13.3.0+git8781-1.16.1
libsystemd0-228-157.72.1
libtasn1-4.9-3.19.1
libtasn1-6-4.9-3.19.1
libudev1-228-157.72.1
libuuid1-2.33.2-4.45.2
libxml2-2-2.9.4-46.93.1
libxslt1-1.1.28-17.21.1
libyui-ncurses7-2.48.3-7.3.6
libz1-1.2.11-11.37.1
libzmq3-4.0.4-15.8.1
libzypp-16.22.16-75.1
mozilla-nspr-4.36.2-19.36.1
mozilla-nss-certs-3.112.2-58.133.1
ncurses-utils-5.9-88.1
net-tools-1.60-765.15.1
nfs-client-1.3.0-34.53.5
nfs-kernel-server-1.3.0-34.53.5
nfsidmap-0.25-7.6.1
nscd-2.22-114.40.1
ntp-4.2.8p17-106.7.1
openldap2-client-2.4.41-22.26.9
openslp-2.0.0-24.5.2
openssh-7.2p2-81.34.1
openssl-1_0_0-1.0.2p-3.98.1
pam-1.1.8-24.77.1
pam-config-0.89-5.8.1
patterns-sles-Minimal-12-12.12.1
pciutils-3.5.6-11.12.1
perl-5.18.2-12.29.1
perl-Bootloader-0.947-3.9.1
perl-base-5.18.2-12.29.1
polkit-0.113-5.30.1
procps-3.3.9-11.33.1
python-2.7.18-33.56.1
python-base-2.7.18-33.56.1
python-bind-9.11.22-3.65.1
python-chardet-3.0.4-5.9.2
python-idna-2.5-3.13.1
python-pyOpenSSL-17.1.0-4.29.1
python-requests-2.24.0-8.23.1
python-setuptools-40.6.2-4.27.1
python-urllib3-1.25.10-3.43.1
python-xml-2.7.18-33.56.1
python3-3.4.10-25.169.1
python3-base-3.4.10-25.169.1
python3-chardet-3.0.4-5.9.2
python3-idna-2.5-3.13.1
python3-pyOpenSSL-17.1.0-4.29.1
python3-requests-2.24.0-8.20.1
python3-setuptools-40.6.2-4.27.1
python3-typing-3.10.0.0-3.3.1
python3-urllib3-1.25.10-3.43.1
python36-base-3.6.15-97.1
regionServiceClientConfigGCE-5.0.0-5.21.1
release-notes-sles-12.5.20250211-3.52.4
rsync-3.1.3-3.34.1
rsyslog-8.2106.0-8.17.4
ruby2.1-2.1.9-19.9.1
ruby2.1-stdlib-2.1.9-19.9.1
samba-client-libs-4.15.13+git.664.e8416d8d213-3.99.1
samba-libs-4.15.13+git.664.e8416d8d213-3.99.1
screen-4.0.4-23.9.1
shadow-4.2.1-36.15.1
shim-15.8-25.30.1
sles-release-12.5-9.5.2
sles-release-POOL-12.5-9.5.2
sqlite3-tcl-3.50.2-9.41.1
sudo-1.8.27-4.54.1
supportutils-3.0.12-95.57.1
supportutils-plugin-suse-public-cloud-1.0.9-6.22.1
suse-build-key-12.0-7.22.1
suse-module-tools-12.13-3.11.1
systemd-228-157.72.1
systemd-sysvinit-228-157.72.1
tar-1.27.1-15.24.1
terminfo-5.9-88.1
terminfo-base-5.9-88.1
timezone-2025b-74.85.2
udev-228-157.72.1
util-linux-2.33.2-4.45.2
util-linux-systemd-2.33.2-4.45.2
vim-9.1.1629-17.54.1
vim-data-common-9.1.1629-17.54.1
wget-1.14-21.25.1
wicked-0.6.77-3.53.1
wicked-service-0.6.77-3.53.1
xfsprogs-4.15.0-3.28.1
yast2-network-3.4.12-3.6.4
yast2-registration-3.3.2-3.7.4
zypper-1.13.67-21.64.1
augeas-1.10.1-4.6.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
augeas-lenses-1.10.1-4.6.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
autofs-5.1.3-3.17.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
bash-4.3-83.36.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
bind-utils-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
ca-certificates-1_201403302107-15.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
ca-certificates-mozilla-2.74-12.51.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cloud-netconfig-gce-1.14-35.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cloud-regionsrv-client-10.5.2-52.132.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cloud-regionsrv-client-plugin-gce-1.0.0-52.132.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
coreutils-8.25-13.19.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cpio-2.11-36.21.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cups-libs-1.7.5-20.57.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
curl-8.0.1-11.114.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cyrus-sasl-2.1.26-14.7.9 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cyrus-sasl-digestmd5-2.1.26-14.7.9 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cyrus-sasl-gssapi-2.1.26-14.7.9 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cyrus-sasl-plain-2.1.26-14.7.9 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
cyrus-sasl-saslauthd-2.1.26-14.7.8 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
expat-2.7.1-21.46.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
fdupes-1.61-8.3.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
glib2-tools-2.48.2-12.55.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
glibc-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
glibc-i18ndata-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
glibc-locale-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
google-guest-agent-20250506.01-1.53.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
google-guest-configs-20241205.00-1.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
google-guest-oslogin-20240311.00-1.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
google-osconfig-agent-20250416.02-1.41.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
grep-2.16-4.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
grub2-2.02-193.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
grub2-i386-pc-2.02-193.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
grub2-x86_64-efi-2.02-193.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
iputils-s20161105-11.12.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
kbd-2.0.4-8.13.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
kbd-legacy-2.0.4-8.13.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
kernel-default-4.12.14-122.283.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
krb5-1.16.3-46.21.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
krb5-client-1.16.3-46.21.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
ksh-93vu-19.3.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
less-458-7.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libX11-6-1.6.2-12.36.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libX11-data-1.6.2-12.36.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libapparmor1-2.8.2-56.26.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libaugeas0-1.10.1-4.6.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libavahi-client3-0.6.32-32.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libavahi-common3-0.6.32-32.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libbind9-161-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libblkid1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libcurl4-8.0.1-11.114.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libdb-4_8-4.8.30-38.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libdns1110-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libexpat1-2.7.1-21.46.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libfastjson4-0.99.8-3.6.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libfdisk1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libfreetype6-2.6.3-7.24.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libgcc_s1-13.3.0+git8781-1.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libgcrypt20-1.6.1-16.86.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libgio-2_0-0-2.48.2-12.55.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libglib-2_0-0-2.48.2-12.55.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libgmodule-2_0-0-2.48.2-12.55.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libgnutls30-3.4.17-8.20.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libgobject-2_0-0-2.48.2-12.55.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libicu52_1-52.1-8.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libicu52_1-data-52.1-8.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libirs161-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libisc1107-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libisccc161-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libisccfg163-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libldap-2_4-2-2.4.41-22.26.9 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
liblwres161-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libmount1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libncurses5-5.9-88.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libncurses6-5.9-88.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libnghttp2-14-1.39.2-3.18.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libopenssl1_0_0-1.0.2p-3.98.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libopenssl1_1-1.1.1d-2.119.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libpcap1-1.8.1-10.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libpci3-3.5.6-11.12.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libpng16-16-1.6.8-15.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libpolkit0-0.113-5.30.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libprocps3-3.3.9-11.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libpython2_7-1_0-2.7.18-33.56.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libpython3_4m1_0-3.4.10-25.169.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libpython3_6m1_0-3.6.15-97.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libreadline6-6.3-83.36.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libruby2_1-2_1-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libsasl2-3-2.1.26-14.7.9 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libseccomp2-2.5.3-11.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libsmartcols1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libsqlite3-0-3.50.2-9.41.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libssh4-0.9.8-3.18.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libstdc++6-13.3.0+git8781-1.16.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libsystemd0-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libtasn1-4.9-3.19.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libtasn1-6-4.9-3.19.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libudev1-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libuuid1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libxml2-2-2.9.4-46.93.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libxslt1-1.1.28-17.21.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libyui-ncurses7-2.48.3-7.3.6 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libz1-1.2.11-11.37.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libzmq3-4.0.4-15.8.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
libzypp-16.22.16-75.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
mozilla-nspr-4.36.2-19.36.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
mozilla-nss-certs-3.112.2-58.133.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
ncurses-utils-5.9-88.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
net-tools-1.60-765.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
nfs-client-1.3.0-34.53.5 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
nfs-kernel-server-1.3.0-34.53.5 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
nfsidmap-0.25-7.6.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
nscd-2.22-114.40.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
ntp-4.2.8p17-106.7.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
openldap2-client-2.4.41-22.26.9 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
openslp-2.0.0-24.5.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
openssh-7.2p2-81.34.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
openssl-1_0_0-1.0.2p-3.98.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
pam-1.1.8-24.77.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
pam-config-0.89-5.8.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
patterns-sles-Minimal-12-12.12.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
pciutils-3.5.6-11.12.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
perl-5.18.2-12.29.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
perl-Bootloader-0.947-3.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
perl-base-5.18.2-12.29.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
polkit-0.113-5.30.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
procps-3.3.9-11.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-2.7.18-33.56.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-base-2.7.18-33.56.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-bind-9.11.22-3.65.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-chardet-3.0.4-5.9.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-idna-2.5-3.13.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-pyOpenSSL-17.1.0-4.29.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-requests-2.24.0-8.23.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-setuptools-40.6.2-4.27.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-urllib3-1.25.10-3.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python-xml-2.7.18-33.56.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-3.4.10-25.169.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-base-3.4.10-25.169.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-chardet-3.0.4-5.9.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-idna-2.5-3.13.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-pyOpenSSL-17.1.0-4.29.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-requests-2.24.0-8.20.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-setuptools-40.6.2-4.27.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-typing-3.10.0.0-3.3.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python3-urllib3-1.25.10-3.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
python36-base-3.6.15-97.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
regionServiceClientConfigGCE-5.0.0-5.21.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
release-notes-sles-12.5.20250211-3.52.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
rsync-3.1.3-3.34.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
rsyslog-8.2106.0-8.17.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
ruby2.1-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
ruby2.1-stdlib-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
samba-client-libs-4.15.13+git.664.e8416d8d213-3.99.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
samba-libs-4.15.13+git.664.e8416d8d213-3.99.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
screen-4.0.4-23.9.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
shadow-4.2.1-36.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
shim-15.8-25.30.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
sles-release-12.5-9.5.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
sles-release-POOL-12.5-9.5.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
sqlite3-tcl-3.50.2-9.41.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
sudo-1.8.27-4.54.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
supportutils-3.0.12-95.57.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
supportutils-plugin-suse-public-cloud-1.0.9-6.22.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
suse-build-key-12.0-7.22.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
suse-module-tools-12.13-3.11.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
systemd-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
systemd-sysvinit-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
tar-1.27.1-15.24.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
terminfo-5.9-88.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
terminfo-base-5.9-88.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
timezone-2025b-74.85.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
udev-228-157.72.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
util-linux-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
util-linux-systemd-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
vim-9.1.1629-17.54.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
vim-data-common-9.1.1629-17.54.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
wget-1.14-21.25.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
wicked-0.6.77-3.53.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
wicked-service-0.6.77-3.53.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
xfsprogs-4.15.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
yast2-network-3.4.12-3.6.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
yast2-registration-3.3.2-3.7.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
zypper-1.13.67-21.64.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64
Directory traversal vulnerability in the (1) extract and (2) extractall functions in the tarfile module in Python allows user-assisted remote attackers to overwrite arbitrary files via a .. (dot dot) sequence in filenames in a TAR archive, a related issue to CVE-2001-1267.
CVE-2007-4559
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
Expat, when used in a parser that has not called XML_SetHashSalt or passed it a seed of 0, makes it easier for context-dependent attackers to defeat cryptographic protection mechanisms via vectors involving use of the srand function.
CVE-2012-6702
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
4.3
AV:N/AC:M/Au:N/C:N/I:P/A:N
expat before version 2.4.0 does not properly handle entities expansion unless an application developer uses the XML_SetEntityDeclHandler function, which allows remote attackers to cause a denial of service (resource consumption), send HTTP requests to intranet servers, or read arbitrary files via a crafted XML document, aka an XML External Entity (XXE) issue. NOTE: it could be argued that because expat already provides the ability to disable external entity expansion, the responsibility for resolving this issue lies with application developers; according to this argument, this entry should be REJECTed, and each affected application would need its own CVE.
CVE-2013-0340
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees
CVE-2013-4235
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:shadow-4.2.1-36.15.1
moderate
3.3
AV:L/AC:M/Au:N/C:N/I:P/A:P
The png_push_read_chunk function in pngpread.c in the progressive decoder in libpng 1.6.x through 1.6.9 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via an IDAT chunk with a length of zero.
CVE-2014-0333
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
moderate
5
AV:N/AC:L/Au:N/C:N/I:N/A:P
The kadm5_randkey_principal_3 function in lib/kadm5/srv/svr_principal.c in kadmind in MIT Kerberos 5 (aka krb5) before 1.13 sends old keys in a response to a -randkey -keepold request, which allows remote authenticated users to forge tickets by leveraging administrative access.
CVE-2014-5351
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
moderate
2.1
AV:N/AC:H/Au:S/C:P/I:N/A:N
Heap-based buffer overflow in the png_combine_row function in libpng before 1.5.21 and 1.6.x before 1.6.16, when running on 64-bit systems, might allow context-dependent attackers to execute arbitrary code via a "very wide interlaced" PNG image.
CVE-2014-9495
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
critical
10
AV:N/AC:L/Au:N/C:C/I:C/A:C
Buffer overflow in the png_read_IDAT_data function in pngrutil.c in libpng before 1.5.21 and 1.6.x before 1.6.16 allows context-dependent attackers to execute arbitrary code via IDAT data with a large width, a different vulnerability than CVE-2014-9495.
CVE-2015-0973
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
Multiple buffer overflows in the (1) png_set_PLTE and (2) png_get_PLTE functions in libpng before 1.0.64, 1.1.x and 1.2.x before 1.2.54, 1.3.x and 1.4.x before 1.4.17, 1.5.x before 1.5.24, and 1.6.x before 1.6.19 allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a small bit-depth value in an IHDR (aka image header) chunk in a PNG image.
CVE-2015-8126
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
moderate
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
The xdr_nullstring function in lib/kadm5/kadm_rpc_xdr.c in kadmind in MIT Kerberos 5 (aka krb5) before 1.13.4 and 1.14.x before 1.14.1 does not verify whether '\0' characters exist as expected, which allows remote authenticated users to obtain sensitive information or cause a denial of service (out-of-bounds read) via a crafted string.
CVE-2015-8629
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
low
2.1
AV:N/AC:H/Au:S/C:P/I:N/A:N
The (1) kadm5_create_principal_3 and (2) kadm5_modify_principal functions in lib/kadm5/srv/svr_principal.c in kadmind in MIT Kerberos 5 (aka krb5) 1.12.x and 1.13.x before 1.13.4 and 1.14.x before 1.14.1 allow remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) by specifying KADM5_POLICY with a NULL policy name.
CVE-2015-8630
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
low
5
AV:N/AC:L/Au:N/C:N/I:N/A:P
Multiple memory leaks in kadmin/server/server_stubs.c in kadmind in MIT Kerberos 5 (aka krb5) before 1.13.4 and 1.14.x before 1.14.1 allow remote authenticated users to cause a denial of service (memory consumption) via a request specifying a NULL principal name.
CVE-2015-8631
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
moderate
4
AV:N/AC:L/Au:S/C:N/I:N/A:P
An integer overflow during the parsing of XML using the Expat library. This vulnerability affects Firefox < 50.
CVE-2016-9063
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
critical
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.
CVE-2017-5753
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
4.7
AV:L/AC:M/Au:N/C:C/I:N/A:N
XML External Entity vulnerability in libexpat 2.2.0 and earlier (Expat XML Parser Library) allows attackers to put the parser in an infinite loop using a malformed external entity definition from an external DTD.
CVE-2017-9233
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
5
AV:N/AC:L/Au:N/C:N/I:N/A:P
The commandline package update tool zypper writes HTTP proxy credentials into its logfile, allowing local attackers to gain access to proxies used.
CVE-2017-9271
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libzypp-16.22.16-75.1
moderate
2.1
AV:L/AC:L/Au:N/C:P/I:N/A:N
Python Cryptographic Authority pyopenssl version prior to version 17.5.0 contains a CWE-416: Use After Free vulnerability in X509 object handling that can result in Use after free can lead to possible denial of service or remote code execution.. This attack appear to be exploitable via Depends on the calling application and if it retains a reference to the memory.. This vulnerability appears to have been fixed in 17.5.0.
CVE-2018-1000807
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-pyOpenSSL-17.1.0-4.29.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-pyOpenSSL-17.1.0-4.29.1
moderate
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
In libexpat in Expat before 2.2.7, XML input including XML names that contain a large number of colons could make the XML parser consume a high amount of RAM and CPU resources while processing (enough to be usable for denial-of-service attacks).
CVE-2018-20843
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
7.8
AV:N/AC:L/Au:N/C:N/I:N/A:C
In ksh version 20120801, a flaw was found in the way it evaluates certain environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Services and applications that allow remote unauthenticated attackers to provide one of those environment variables could allow them to exploit this issue remotely.
CVE-2019-14868
moderate
7.2
AV:L/AC:L/Au:N/C:C/I:C/A:C
A flaw was found with the libssh API function ssh_scp_new() in versions before 0.9.3 and before 0.8.8. When the libssh SCP client connects to a server, the scp command, which includes a user-provided path, is executed on the server-side. In case the library is used in a way where users can influence the third parameter of the function, it would become possible for an attacker to inject arbitrary commands, leading to a compromise of the remote target.
CVE-2019-14889
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
important
9.3
AV:N/AC:M/Au:N/C:C/I:C/A:C
In libexpat before 2.2.8, crafted XML input could fool the parser into changing from DTD parsing to document parsing too early; a consecutive call to XML_GetCurrentLineNumber (or XML_GetCurrentColumnNumber) then resulted in a heap-based buffer over-read.
CVE-2019-15903
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
5
AV:N/AC:L/Au:N/C:N/I:N/A:P
In the Linux kernel, the following vulnerability has been resolved:
netlabel: fix out-of-bounds memory accesses
There are two array out-of-bounds memory accesses, one in
cipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk(). Both
errors are embarassingly simple, and the fixes are straightforward.
As a FYI for anyone backporting this patch to kernels prior to v4.8,
you'll want to apply the netlbl_bitmap_walk() patch to
cipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist before
Linux v4.8.
CVE-2019-25160
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: Fix a potential use after free
Free the adap structure only after we are done using it.
This patch just moves the put_device() down a bit to avoid the
use after free.
[wsa: added comment to the code, added Fixes tag]
CVE-2019-25162
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may allow an unauthenticated user to complete authentication without pairing credentials via adjacent access. An unauthenticated, adjacent attacker could impersonate a Bluetooth BR/EDR master or slave to pair with a previously paired remote device to successfully complete the authentication procedure without knowing the link key.
CVE-2020-10135
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
4.8
AV:A/AC:L/Au:N/C:P/I:P/A:N
A flaw was found in python. In algorithms with quadratic time complexity using non-binary bases, when using int("text"), a system could take 50ms to parse an int string with 100,000 digits and 5s for 1,000,000 digits (float, decimal, int.from_bytes(), and int() for binary bases 2, 4, 8, 16, and 32 are not affected). The highest threat from this vulnerability is to system availability.
CVE-2020-10735
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
json-c through 0.14 has an integer overflow and out-of-bounds write via a large JSON file, as demonstrated by printbuf_memappend.
CVE-2020-12762
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libfastjson4-0.99.8-3.6.1
important
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
libssh 0.9.4 has a NULL pointer dereference in tftpserver.c if ssh_buffer_new returns NULL.
CVE-2020-16135
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
4.3
AV:N/AC:M/Au:N/C:N/I:N/A:P
A flaw was found in libssh versions before 0.8.9 and before 0.9.4 in the way it handled AES-CTR (or DES ciphers if enabled) ciphers. The server or client could crash when the connection hasn't been fully initialized and the system tries to cleanup the ciphers when closing the connection. The biggest threat from this vulnerability is system availability.
CVE-2020-1730
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
5
AV:N/AC:L/Au:N/C:N/I:N/A:P
Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification 1.0B through 5.2 may permit an unauthenticated nearby device to spoof the BD_ADDR of the peer device to complete pairing without knowledge of the PIN.
CVE-2020-26555
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
4.8
AV:A/AC:L/Au:N/C:P/I:P/A:N
Bluetooth LE and BR/EDR secure pairing in Bluetooth Core Specification 2.1 through 5.2 may permit a nearby man-in-the-middle attacker to identify the Passkey used during pairing (in the Passkey authentication procedure) by reflection of the public key and the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. The attack methodology determines the Passkey value one bit at a time.
CVE-2020-26558
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
4.3
AV:A/AC:M/Au:N/C:P/I:P/A:N
An issue was discovered in the Linux kernel before 5.8.10. virt/kvm/kvm_main.c has a kvm_io_bus_unregister_dev memory leak upon a kmalloc failure, aka CID-f65886606c2d.
CVE-2020-36312
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
2.1
AV:L/AC:L/Au:N/C:N/I:N/A:P
In the Linux kernel, the following vulnerability has been resolved:
media: dvbdev: Fix memory leak in dvb_media_device_free()
dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn`
before setting it to NULL, as documented in include/media/media-device.h:
"The media_entity instance itself must be freed explicitly by the driver
if required."
CVE-2020-36777
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: cadence: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in functions cdns_i2c_master_xfer and cdns_reg_slave.
However, pm_runtime_get_sync will increment pm usage counter
even failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced.
CVE-2020-36784
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context
If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but
not always, the case), the 'WARN_ON(in_irq)' in
net/core/skbuff.c#skb_release_head_state() might be triggered, under network
congestion circumstances, together with the potential risk of a NULL pointer
dereference.
The root cause of this issue is the call to kfree_skb() instead of
dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().
This patch prevents the skb to be freed within the call to netif_rx() by
incrementing its reference count with skb_get(). The skb is finally freed by
one of the in-irq-context safe functions: dev_consume_skb_any() or
dev_kfree_skb_any(). The "any" version is used because some drivers might call
can_get_echo_skb() in a normal context.
The reason for this issue to occur is that initially, in the core network
stack, loopback skb were not supposed to be received in hardware IRQ context.
The CAN stack is an exeption.
This bug was previously reported back in 2017 in [1] but the proposed patch
never got accepted.
While [1] directly modifies net/core/dev.c, we try to propose here a
smoother modification local to CAN network stack (the assumption
behind is that only CAN devices are affected by this issue).
[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com
CVE-2020-36789
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: keep alloc_hash updated after hash allocation
In commit 599be01ee567 ("net_sched: fix an OOB access in cls_tcindex")
I moved cp->hash calculation before the first
tcindex_alloc_perfect_hash(), but cp->alloc_hash is left untouched.
This difference could lead to another out of bound access.
cp->alloc_hash should always be the size allocated, we should
update it after this tcindex_alloc_perfect_hash().
CVE-2020-36791
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Improper access control in BlueZ may allow an authenticated user to potentially enable information disclosure via adjacent access.
CVE-2021-0129
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
2.7
AV:A/AC:L/Au:S/C:P/I:N/A:N
A flaw was found in s390 eBPF JIT in bpf_jit_insn in arch/s390/net/bpf_jit_comp.c in the Linux kernel. In this flaw, a local attacker with special user privilege can circumvent the verifier and may lead to a confidentiality problem.
CVE-2021-20320
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
2.1
AV:L/AC:L/Au:N/C:P/I:N/A:N
Use After Free vulnerability in nfc sockets in the Linux Kernel before 5.12.4 allows local attackers to elevate their privileges. In typical configurations, the issue can only be triggered by a privileged local user with the CAP_NET_RAW capability.
CVE-2021-23134
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
4.6
AV:L/AC:L/Au:N/C:P/I:P/A:P
Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character.
CVE-2021-3156
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sudo-1.8.27-4.54.1
important
7.2
AV:L/AC:L/Au:N/C:C/I:C/A:C
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-v20260125-x86-64:wget-1.14-21.25.1
moderate
5.8
AV:N/AC:M/Au:N/C:P/I:P/A:N
kernel/bpf/verifier.c in the Linux kernel through 5.12.7 enforces incorrect limits for pointer arithmetic operations, aka CID-bb01a1bba579. This can be abused to perform out-of-bounds reads and writes in kernel memory, leading to local privilege escalation to root. In particular, there is a corner case where the off reg causes a masking direction change, which then results in an incorrect final aux->alu_limit.
CVE-2021-33200
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
7.2
AV:L/AC:L/Au:N/C:C/I:C/A:C
Integer Overflow or Wraparound vulnerability in openEuler kernel on Linux (filesystem modules) allows Forced Integer Overflow.This issue affects openEuler kernel: from 4.19.90 before 4.19.90-2401.3, from 5.10.0-60.18.0 before 5.10.0-183.0.0.
CVE-2021-33631
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secret_hash and the other session_id. Initially, both of them are the same, but after key re-exchange, previous session_id is kept and used as an input to new secret_hash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating "secret_hash" of different size than the session_id has. This becomes an issue when the session_id memory is zeroed or when it is used again during second key re-exchange.
CVE-2021-3634
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
low
4
AV:N/AC:L/Au:S/C:N/I:N/A:P
The Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.5 and 1.19.x before 1.19.3 has a NULL pointer dereference in kdc/do_tgs_req.c via a FAST inner body that lacks a server field.
CVE-2021-37750
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
moderate
4
AV:N/AC:L/Au:S/C:N/I:N/A:P
A vulnerability was found in the Linux kernel's EBPF verifier when handling internal data structures. Internal memory locations could be returned to userspace. A local attacker with the permissions to insert eBPF code to the kernel can use this to leak internal kernel memory details defeating some of the exploit mitigations in place for the kernel.
CVE-2021-4159
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in the Linux kernel before 5.14.15. There is an array-index-out-of-bounds flaw in the detach_capi_ctr function in drivers/isdn/capi/kcapi.c.
CVE-2021-43389
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
2.1
AV:L/AC:L/Au:N/C:N/I:N/A:P
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: Drop USERGS_SYSRET64 paravirt call
commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.
USERGS_SYSRET64 is used to return from a syscall via SYSRET, but
a Xen PV guest will nevertheless use the IRET hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just use
the iret exit from the beginning.
This can easily be done via an ALTERNATIVE like it is done for the
sysenter compat case already.
It should be noted that this drops the optimization in Xen for not
restoring a few registers when returning to user mode, but it seems
as if the saved instructions in the kernel more than compensate for
this drop (a kernel build in a Xen PV guest was slightly faster with
this patch applied).
While at it remove the stale sysret32 remnants.
[ pawan: Brad Spengler and Salvatore Bonaccorso <carnil@debian.org>
reported a problem with the 5.10 backport commit edc702b4a820
("x86/entry_64: Add VERW just before userspace transition").
When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in
syscall_return_via_sysret path as USERGS_SYSRET64 is runtime
patched to:
.cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,
0x48, 0x0f, 0x07 }, // swapgs; sysretq
which is missing CLEAR_CPU_BUFFERS. It turns out dropping
USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS
to be explicitly added to syscall_return_via_sysret path. Below
is with CONFIG_PARAVIRT_XXL=y and this patch applied:
syscall_return_via_sysret:
...
<+342>: swapgs
<+345>: xchg %ax,%ax
<+347>: verw -0x1a2(%rip) <------
<+354>: sysretq
]
CVE-2021-4440
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
doing a shift operation where the number of bits shifted equals
number of bits in the operand. This behaviour is undefined.
Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
count is >= number of bits in the operand.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
CVE-2021-4460
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In Expat (aka libexpat) before 2.4.3, a left shift by 29 (or more) places in the storeAtts function in xmlparse.c can lead to realloc misbehavior (e.g., allocating too few bytes, or only freeing memory).
CVE-2021-45960
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
9
AV:N/AC:L/Au:S/C:C/I:C/A:C
In doProlog in xmlparse.c in Expat (aka libexpat) before 2.4.3, an integer overflow exists for m_groupSize.
CVE-2021-46143
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
In the Linux kernel, the following vulnerability has been resolved:
net: hso: fix null-ptr-deref during tty device unregistration
Multiple ttys try to claim the same the minor number causing a double
unregistration of the same device. The first unregistration succeeds
but the next one results in a null-ptr-deref.
The get_free_serial_index() function returns an available minor number
but doesn't assign it immediately. The assignment is done by the caller
later. But before this assignment, calls to get_free_serial_index()
would return the same minor number.
Fix this by modifying get_free_serial_index to assign the minor number
immediately after one is found to be and rename it to obtain_minor()
to better reflect what it does. Similary, rename set_serial_by_index()
to release_minor() and modify it to free up the minor number of the
given hso_serial. Every obtain_minor() should have corresponding
release_minor() call.
CVE-2021-46904
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: hso: fix NULL-deref on disconnect regression
Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device
unregistration") fixed the racy minor allocation reported by syzbot, but
introduced an unconditional NULL-pointer dereference on every disconnect
instead.
Specifically, the serial device table must no longer be accessed after
the minor has been released by hso_serial_tty_unregister().
CVE-2021-46905
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: fix info leak in hid_submit_ctrl
In hid_submit_ctrl(), the way of calculating the report length doesn't
take into account that report->size can be zero. When running the
syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
calculate transfer_buffer_length as 16384. When this urb is passed to
the usb core layer, KMSAN reports an info leak of 16384 bytes.
To fix this, first modify hid_report_len() to account for the zero
report size case by using DIV_ROUND_UP for the division. Then, call it
from hid_submit_ctrl().
CVE-2021-46906
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ARM: footbridge: fix PCI interrupt mapping
Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()"), the PCI code will call the IRQ mapping function
whenever a PCI driver is probed. If these are marked as __init, this
causes an oops if a PCI driver is loaded or bound after the kernel has
initialised.
CVE-2021-46909
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_limit: avoid possible divide error in nft_limit_init
div_u64() divides u64 by u32.
nft_limit_init() wants to divide u64 by u64, use the appropriate
math function (div64_u64)
divide error: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline]
RIP: 0010:div_u64 include/linux/math64.h:127 [inline]
RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85
Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00
RSP: 0018:ffffc90009447198 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003
RBP: ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000
R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]
nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713
nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160
nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321
nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456
nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline]
nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598
netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-46915
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
locking/qrwlock: Fix ordering in queued_write_lock_slowpath()
While this code is executed with the wait_lock held, a reader can
acquire the lock without holding wait_lock. The writer side loops
checking the value with the atomic_cond_read_acquire(), but only truly
acquires the lock when the compare-and-exchange is completed
successfully which isn't ordered. This exposes the window between the
acquire and the cmpxchg to an A-B-A problem which allows reads
following the lock acquisition to observe values speculatively before
the write lock is truly acquired.
We've seen a problem in epoll where the reader does a xchg while
holding the read lock, but the writer can see a value change out from
under it.
Writer | Reader
--------------------------------------------------------------------------------
ep_scan_ready_list() |
|- write_lock_irq() |
|- queued_write_lock_slowpath() |
|- atomic_cond_read_acquire() |
| read_lock_irqsave(&ep->lock, flags);
--> (observes value before unlock) | chain_epi_lockless()
| | epi->next = xchg(&ep->ovflist, epi);
| | read_unlock_irqrestore(&ep->lock, flags);
| |
| atomic_cmpxchg_relaxed() |
|-- READ_ONCE(ep->ovflist); |
A core can order the read of the ovflist ahead of the
atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire
semantics addresses this issue at which point the atomic_cond_read can
be switched to use relaxed semantics.
[peterz: use try_cmpxchg()]
CVE-2021-46921
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFC: st21nfca: Fix memory leak in device probe and remove
'phy->pending_skb' is alloced when device probe, but forgot to free
in the error handling path and remove path, this cause memory leak
as follows:
unreferenced object 0xffff88800bc06800 (size 512):
comm "8", pid 11775, jiffies 4295159829 (age 9.032s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450
[<00000000c93382b3>] kmalloc_reserve+0x37/0xd0
[<000000005fea522c>] __alloc_skb+0x124/0x380
[<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2
Fix it by freeing 'pending_skb' in error and remove.
CVE-2021-46924
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix kernel panic caused by race of smc_sock
A crash occurs when smc_cdc_tx_handler() tries to access smc_sock
but smc_release() has already freed it.
[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88
[ 4570.696048] #PF: supervisor write access in kernel mode
[ 4570.696728] #PF: error_code(0x0002) - not-present page
[ 4570.697401] PGD 0 P4D 0
[ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111
[ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0
[ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30
<...>
[ 4570.711446] Call Trace:
[ 4570.711746] <IRQ>
[ 4570.711992] smc_cdc_tx_handler+0x41/0xc0
[ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560
[ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10
[ 4570.713489] tasklet_action_common.isra.17+0x66/0x140
[ 4570.714083] __do_softirq+0x123/0x2f4
[ 4570.714521] irq_exit_rcu+0xc4/0xf0
[ 4570.714934] common_interrupt+0xba/0xe0
Though smc_cdc_tx_handler() checked the existence of smc connection,
smc_release() may have already dismissed and released the smc socket
before smc_cdc_tx_handler() further visits it.
smc_cdc_tx_handler() |smc_release()
if (!conn) |
|
|smc_cdc_tx_dismiss_slots()
| smc_cdc_tx_dismisser()
|
|sock_put(&smc->sk) <- last sock_put,
| smc_sock freed
bh_lock_sock(&smc->sk) (panic) |
To make sure we won't receive any CDC messages after we free the
smc_sock, add a refcount on the smc_connection for inflight CDC
message(posted to the QP but haven't received related CQE), and
don't release the smc_connection until all the inflight CDC messages
haven been done, for both success or failed ones.
Using refcount on CDC messages brings another problem: when the link
is going to be destroyed, smcr_link_clear() will reset the QP, which
then remove all the pending CQEs related to the QP in the CQ. To make
sure all the CQEs will always come back so the refcount on the
smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced
by smc_ib_modify_qp_error().
And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we
need to wait for all pending WQEs done, or we may encounter use-after-
free when handling CQEs.
For IB device removal routine, we need to wait for all the QPs on that
device been destroyed before we can destroy CQs on the device, or
the refcount on smc_connection won't reach 0 and smc_sock cannot be
released.
CVE-2021-46925
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Input: appletouch - initialize work before device registration
Syzbot has reported warning in __flush_work(). This warning is caused by
work->func == NULL, which means missing work initialization.
This may happen, since input_dev->close() calls
cancel_work_sync(&dev->work), but dev->work initalization happens _after_
input_register_device() call.
So this patch moves dev->work initialization before registering input
device
CVE-2021-46932
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.
ffs_data_clear is indirectly called from both ffs_fs_kill_sb and
ffs_ep0_release, so it ends up being called twice when userland closes ep0
and then unmounts f_fs.
If userland provided an eventfd along with function's USB descriptors, it
ends up calling eventfd_ctx_put as many times, causing a refcount
underflow.
NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.
Also, set epfiles to NULL right after de-allocating it, for readability.
For completeness, ffs_data_clear actually ends up being called thrice, the
last call being before the whole ffs structure gets freed, so when this
specific sequence happens there is a second underflow happening (but not
being reported):
/sys/kernel/debug/tracing# modprobe usb_f_fs
/sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter
/sys/kernel/debug/tracing# echo function > current_tracer
/sys/kernel/debug/tracing# echo 1 > tracing_on
(setup gadget, run and kill function userland process, teardown gadget)
/sys/kernel/debug/tracing# echo 0 > tracing_on
/sys/kernel/debug/tracing# cat trace
smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed
smartcard-openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed
smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put
Warning output corresponding to above trace:
[ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c
[ 1946.293094] refcount_t: underflow; use-after-free.
[ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E)
[ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1
[ 1946.417950] Hardware name: BCM2835
[ 1946.425442] Backtrace:
[ 1946.432048] [<c08d60a0>] (dump_backtrace) from [<c08d62ec>] (show_stack+0x20/0x24)
[ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c
[ 1946.458412] [<c08d62cc>] (show_stack) from [<c08d9ae0>] (dump_stack+0x28/0x30)
[ 1946.470380] [<c08d9ab8>] (dump_stack) from [<c0123500>] (__warn+0xe8/0x154)
[ 1946.482067] r5:c04a948c r4:c0a71dc8
[ 1946.490184] [<c0123418>] (__warn) from [<c08d6948>] (warn_slowpath_fmt+0xa0/0xe4)
[ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04
[ 1946.517070] [<c08d68ac>] (warn_slowpath_fmt) from [<c04a948c>] (refcount_warn_saturate+0x110/0x15c)
[ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0
[ 1946.546708] [<c04a937c>] (refcount_warn_saturate) from [<c0380134>] (eventfd_ctx_put+0x48/0x74)
[ 1946.564476] [<c03800ec>] (eventfd_ctx_put) from [<bf5464e8>] (ffs_data_clear+0xd0/0x118 [usb_f_fs])
[ 1946.582664] r5:c3b84c00 r4:c2695b00
[ 1946.590668] [<bf546418>] (ffs_data_clear [usb_f_fs]) from [<bf547cc0>] (ffs_data_closed+0x9c/0x150 [usb_f_fs])
[ 1946.609608] r5:bf54d014 r4:c2695b00
[ 1946.617522] [<bf547c24>] (ffs_data_closed [usb_f_fs]) from [<bf547da0>] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs])
[ 1946.636217] r7:c0dfcb
---truncated---
CVE-2021-46933
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fix use-after-free in tw_timer_handler
A real world panic issue was found as follow in Linux 5.4.
BUG: unable to handle page fault for address: ffffde49a863de28
PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
RIP: 0010:tw_timer_handler+0x20/0x40
Call Trace:
<IRQ>
call_timer_fn+0x2b/0x120
run_timer_softirq+0x1ef/0x450
__do_softirq+0x10d/0x2b8
irq_exit+0xc7/0xd0
smp_apic_timer_interrupt+0x68/0x120
apic_timer_interrupt+0xf/0x20
This issue was also reported since 2017 in the thread [1],
unfortunately, the issue was still can be reproduced after fixing
DCCP.
The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net
namespace is destroyed since tcp_sk_ops is registered befrore
ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops
in the list of pernet_list. There will be a use-after-free on
net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net
if there are some inflight time-wait timers.
This bug is not introduced by commit f2bf415cfed7 ("mib: add net to
NET_ADD_STATS_BH") since the net_statistics is a global variable
instead of dynamic allocation and freeing. Actually, commit
61a7e26028b9 ("mib: put net statistics on struct net") introduces
the bug since it put net statistics on struct net and free it when
net namespace is destroyed.
Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug
and replace pr_crit() with panic() since continuing is meaningless
when init_ipv4_mibs() fails.
[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1
CVE-2021-46936
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails
When loading a device-mapper table for a request-based mapped device,
and the allocation/initialization of the blk_mq_tag_set for the device
fails, a following device remove will cause a double free.
E.g. (dmesg):
device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device
device-mapper: ioctl: unable to set up device queue for new table.
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0305e098835de000 TEID: 0305e098835de803
Fault in home space mode while using kernel ASCE.
AS:000000025efe0007 R3:0000000000000024
Oops: 0038 ilc:3 [#1] SMP
Modules linked in: ... lots of modules ...
Supported: Yes, External
CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3
Hardware name: IBM 8561 T01 7I2 (LPAR)
Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000
000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000
000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640
00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8
Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8
000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58
#000000025e368ec4: e3b010000008 ag %r11,0(%r1)
>000000025e368eca: e310b0080004 lg %r1,8(%r11)
000000025e368ed0: a7110001 tmll %r1,1
000000025e368ed4: a7740129 brc 7,25e369126
000000025e368ed8: e320b0080004 lg %r2,8(%r11)
000000025e368ede: b904001b lgr %r1,%r11
Call Trace:
[<000000025e368eca>] kfree+0x42/0x330
[<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8
[<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]
[<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod]
[<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod]
[<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod]
[<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod]
[<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod]
[<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0
[<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40
[<000000025e8c15ac>] system_call+0xd8/0x2c8
Last Breaking-Event-Address:
[<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8
Kernel panic - not syncing: Fatal exception: panic_on_oops
When allocation/initialization of the blk_mq_tag_set fails in
dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer
is not reset to NULL; so when dev_remove() later gets into
dm_mq_cleanup_mapped_device() it sees the pointer and tries to
uninitialize and free it again.
Fix this by setting the pointer to NULL in dm_mq_init_request_queue()
error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().
CVE-2021-46938
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Restructure trace_clock_global() to never block
It was reported that a fix to the ring buffer recursion detection would
cause a hung machine when performing suspend / resume testing. The
following backtrace was extracted from debugging that case:
Call Trace:
trace_clock_global+0x91/0xa0
__rb_reserve_next+0x237/0x460
ring_buffer_lock_reserve+0x12a/0x3f0
trace_buffer_lock_reserve+0x10/0x50
__trace_graph_return+0x1f/0x80
trace_graph_return+0xb7/0xf0
? trace_clock_global+0x91/0xa0
ftrace_return_to_handler+0x8b/0xf0
? pv_hash+0xa0/0xa0
return_to_handler+0x15/0x30
? ftrace_graph_caller+0xa0/0xa0
? trace_clock_global+0x91/0xa0
? __rb_reserve_next+0x237/0x460
? ring_buffer_lock_reserve+0x12a/0x3f0
? trace_event_buffer_lock_reserve+0x3c/0x120
? trace_event_buffer_reserve+0x6b/0xc0
? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0
? dpm_run_callback+0x3b/0xc0
? pm_ops_is_empty+0x50/0x50
? platform_get_irq_byname_optional+0x90/0x90
? trace_device_pm_callback_start+0x82/0xd0
? dpm_run_callback+0x49/0xc0
With the following RIP:
RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200
Since the fix to the recursion detection would allow a single recursion to
happen while tracing, this lead to the trace_clock_global() taking a spin
lock and then trying to take it again:
ring_buffer_lock_reserve() {
trace_clock_global() {
arch_spin_lock() {
queued_spin_lock_slowpath() {
/* lock taken */
(something else gets traced by function graph tracer)
ring_buffer_lock_reserve() {
trace_clock_global() {
arch_spin_lock() {
queued_spin_lock_slowpath() {
/* DEAD LOCK! */
Tracing should *never* block, as it can lead to strange lockups like the
above.
Restructure the trace_clock_global() code to instead of simply taking a
lock to update the recorded "prev_time" simply use it, as two events
happening on two different CPUs that calls this at the same time, really
doesn't matter which one goes first. Use a trylock to grab the lock for
updating the prev_time, and if it fails, simply try again the next time.
If it failed to be taken, that means something else is already updating
it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761
CVE-2021-46939
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Do core softreset when switch mode
According to the programming guide, to switch mode for DRD controller,
the driver needs to do the following.
To switch from device to host:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(host mode)
3. Reset the host with USBCMD.HCRESET
4. Then follow up with the initializing host registers sequence
To switch from host to device:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(device mode)
3. Reset the device with DCTL.CSftRst
4. Then follow up with the initializing registers sequence
Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of
switching from host to device. John Stult reported a lockup issue seen
with HiKey960 platform without these steps[1]. Similar issue is observed
with Ferry's testing platform[2].
So, apply the required steps along with some fixes to Yu Chen's and John
Stultz's version. The main fixes to their versions are the missing wait
for clocks synchronization before clearing GCTL.CoreSoftReset and only
apply DCTL.CSftRst when switching from host to device.
[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/
[2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
CVE-2021-46941
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: properly indicate failure when ending a failed write request
This patch addresses a data corruption bug in raid1 arrays using bitmaps.
Without this fix, the bitmap bits for the failed I/O end up being cleared.
Since we are in the failure leg of raid1_end_write_request, the request
either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).
CVE-2021-46950
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure
When failing the driver probe because of invalid firmware properties,
the GTDT driver unmaps the interrupt that it mapped earlier.
However, it never checks whether the mapping of the interrupt actially
succeeded. Even more, should the firmware report an illegal interrupt
number that overlaps with the GIC SGI range, this can result in an
IPI being unmapped, and subsequent fireworks (as reported by Dann
Frazier).
Rework the driver to have a slightly saner behaviour and actually
check whether the interrupt has been mapped before unmapping things.
CVE-2021-46953
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix stack OOB read while fragmenting IPv4 packets
running openvswitch on kernels built with KASAN, it's possible to see the
following splat while testing fragmentation of IPv4 packets:
BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
Read of size 1 at addr ffff888112fc713c by task handler2/1367
CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418
Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
Call Trace:
dump_stack+0x92/0xc1
print_address_description.constprop.7+0x1a/0x150
kasan_report.cold.13+0x7f/0x111
ip_do_fragment+0x1b03/0x1f60
ovs_fragment+0x5bf/0x840 [openvswitch]
do_execute_actions+0x1bd5/0x2400 [openvswitch]
ovs_execute_actions+0xc8/0x3d0 [openvswitch]
ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]
genl_family_rcv_msg_doit.isra.15+0x227/0x2d0
genl_rcv_msg+0x287/0x490
netlink_rcv_skb+0x120/0x380
genl_rcv+0x24/0x40
netlink_unicast+0x439/0x630
netlink_sendmsg+0x719/0xbf0
sock_sendmsg+0xe2/0x110
____sys_sendmsg+0x5ba/0x890
___sys_sendmsg+0xe9/0x160
__sys_sendmsg+0xd3/0x170
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f957079db07
Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48
RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07
RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019
RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0
The buggy address belongs to the page:
page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7
flags: 0x17ffffc0000000()
raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:
ovs_fragment+0x0/0x840 [openvswitch]
this frame has 2 objects:
[32, 144) 'ovs_dst'
[192, 424) 'ovs_rt'
Memory state around the buggy address:
ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00
>ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
^
ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00
for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,
in the following call graph:
ip_do_fragment()
ip_skb_dst_mtu()
ip_dst_mtu_maybe_forward()
ip_mtu_locked()
the pointer to struct dst_entry is used as pointer to struct rtable: this
turns the access to struct members like rt_mtu_locked into an OOB read in
the stack. Fix this changing the temporary variable used for IPv4 packets
in ovs_fragment(), similarly to what is done for IPv6 few lines below.
CVE-2021-46955
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between transaction aborts and fsyncs leading to use-after-free
There is a race between a task aborting a transaction during a commit,
a task doing an fsync and the transaction kthread, which leads to an
use-after-free of the log root tree. When this happens, it results in a
stack trace like the following:
BTRFS info (device dm-0): forced readonly
BTRFS warning (device dm-0): Skipping commit of aborted transaction.
BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure
BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5)
BTRFS warning (device dm-0): Skipping commit of aborted transaction.
BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10
BTRFS error (device dm-0): error writing primary super block to device 1
BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10
BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10
BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers)
BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure
general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:__mutex_lock+0x139/0xa40
Code: c0 74 19 (...)
RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202
RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002
RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000
R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040
R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358
FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? __btrfs_handle_fs_error+0xde/0x146 [btrfs]
? btrfs_sync_log+0x7c1/0xf20 [btrfs]
? btrfs_sync_log+0x7c1/0xf20 [btrfs]
btrfs_sync_log+0x7c1/0xf20 [btrfs]
btrfs_sync_file+0x40c/0x580 [btrfs]
do_fsync+0x38/0x70
__x64_sys_fsync+0x10/0x20
do_syscall_64+0x33/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fa9142a55c3
Code: 8b 15 09 (...)
RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3
RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005
RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340
R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0
Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...)
---[ end trace ee2f1b19327d791d ]---
The steps that lead to this crash are the following:
1) We are at transaction N;
2) We have two tasks with a transaction handle attached to transaction N.
Task A and Task B. Task B is doing an fsync;
3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree
into a local variable named 'log_root_tree' at the top of
btrfs_sync_log(). Task B is about to call write_all_supers(), but
before that...
4) Task A calls btrfs_commit_transaction(), and after it sets the
transaction state to TRANS_STATE_COMMIT_START, an error happens before
it w
---truncated---
CVE-2021-46958
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Return correct error code from smb2_get_enc_key
Avoid a warning if the error percolates back up:
[440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key
[440700.386947] ------------[ cut here ]------------
[440700.386948] err = 1
[440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70
...
[440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu
...
[440700.397334] Call Trace:
[440700.397346] __filemap_set_wb_err+0x1a/0x70
[440700.397419] cifs_writepages+0x9c7/0xb30 [cifs]
[440700.397426] do_writepages+0x4b/0xe0
[440700.397444] __filemap_fdatawrite_range+0xcb/0x100
[440700.397455] filemap_write_and_wait+0x42/0xa0
[440700.397486] cifs_setattr+0x68b/0xf30 [cifs]
[440700.397493] notify_change+0x358/0x4a0
[440700.397500] utimes_common+0xe9/0x1c0
[440700.397510] do_utimes+0xc5/0x150
[440700.397520] __x64_sys_utimensat+0x88/0xd0
CVE-2021-46960
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand()
RIP: 0010:kmem_cache_free+0xfa/0x1b0
Call Trace:
qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx]
scsi_queue_rq+0x5e2/0xa40
__blk_mq_try_issue_directly+0x128/0x1d0
blk_mq_request_issue_directly+0x4e/0xb0
Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now
allocated by upper layers. This fixes smatch warning of srb unintended
free.
CVE-2021-46963
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Reserve extra IRQ vectors
Commit a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number of
CPUs") lowers the number of allocated MSI-X vectors to the number of CPUs.
That breaks vector allocation assumptions in qla83xx_iospace_config(),
qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions
computes maximum number of qpairs as:
ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default
response queue) - 1 (ATIO, in dual or pure target mode)
max_qpairs is set to zero in case of two CPUs and initiator mode. The
number is then used to allocate ha->queue_pair_map inside
qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is
left NULL but the driver thinks there are queue pairs available.
qla2xxx_queuecommand() tries to find a qpair in the map and crashes:
if (ha->mqenable) {
uint32_t tag;
uint16_t hwq;
struct qla_qpair *qpair = NULL;
tag = blk_mq_unique_tag(cmd->request);
hwq = blk_mq_unique_tag_to_hwq(tag);
qpair = ha->queue_pair_map[hwq]; # <- HERE
if (qpair)
return qla2xxx_mqueuecommand(host, cmd, qpair);
}
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc]
RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx]
Call Trace:
scsi_queue_rq+0x58c/0xa60
blk_mq_dispatch_rq_list+0x2b7/0x6f0
? __sbitmap_get_word+0x2a/0x80
__blk_mq_sched_dispatch_requests+0xb8/0x170
blk_mq_sched_dispatch_requests+0x2b/0x50
__blk_mq_run_hw_queue+0x49/0xb0
__blk_mq_delay_run_hw_queue+0xfb/0x150
blk_mq_sched_insert_request+0xbe/0x110
blk_execute_rq+0x45/0x70
__scsi_execute+0x10e/0x250
scsi_probe_and_add_lun+0x228/0xda0
__scsi_scan_target+0xf4/0x620
? __pm_runtime_resume+0x4f/0x70
scsi_scan_target+0x100/0x110
fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc]
process_one_work+0x1ea/0x3b0
worker_thread+0x28/0x3b0
? process_one_work+0x3b0/0x3b0
kthread+0x112/0x130
? kthread_park+0x80/0x80
ret_from_fork+0x22/0x30
The driver should allocate enough vectors to provide every CPU it's own HW
queue and still handle reserved (MB, RSP, ATIO) interrupts.
The change fixes the crash on dual core VM and prevents unbalanced QP
allocation where nr_hw_queues is two less than the number of CPUs.
CVE-2021-46964
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: custom_method: fix potential use-after-free issue
In cm_write(), buf is always freed when reaching the end of the
function. If the requested count is less than table.length, the
allocated buffer will be freed but subsequent calls to cm_write() will
still try to access it.
Remove the unconditional kfree(buf) at the end of the function and
set the buf to NULL in the -EINVAL error path to match the rest of
function.
CVE-2021-46966
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nbd: Fix NULL pointer in flush_workqueue
Open /dev/nbdX first, the config_refs will be 1 and
the pointers in nbd_device are still null. Disconnect
/dev/nbdX, then reference a null recv_workq. The
protection by config_refs in nbd_genl_disconnect is useless.
[ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020
[ 656.368943] #PF: supervisor write access in kernel mode
[ 656.369844] #PF: error_code(0x0002) - not-present page
[ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0
[ 656.371693] Oops: 0002 [#1] SMP
[ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1
[ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[ 656.375904] RIP: 0010:mutex_lock+0x29/0x60
[ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d
[ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246
[ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020
[ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318
[ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40
[ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00
[ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000
[ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0
[ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 656.384927] Call Trace:
[ 656.385111] flush_workqueue+0x92/0x6c0
[ 656.385395] nbd_disconnect_and_put+0x81/0xd0
[ 656.385716] nbd_genl_disconnect+0x125/0x2a0
[ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0
[ 656.386422] genl_rcv_msg+0xfc/0x2b0
[ 656.386685] ? nbd_ioctl+0x490/0x490
[ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0
[ 656.387354] netlink_rcv_skb+0x62/0x180
[ 656.387638] genl_rcv+0x34/0x60
[ 656.387874] netlink_unicast+0x26d/0x590
[ 656.388162] netlink_sendmsg+0x398/0x6c0
[ 656.388451] ? netlink_rcv_skb+0x180/0x180
[ 656.388750] ____sys_sendmsg+0x1da/0x320
[ 656.389038] ? ____sys_recvmsg+0x130/0x220
[ 656.389334] ___sys_sendmsg+0x8e/0xf0
[ 656.389605] ? ___sys_recvmsg+0xa2/0xf0
[ 656.389889] ? handle_mm_fault+0x1671/0x21d0
[ 656.390201] __sys_sendmsg+0x6d/0xe0
[ 656.390464] __x64_sys_sendmsg+0x23/0x30
[ 656.390751] do_syscall_64+0x45/0x70
[ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9
To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put().
CVE-2021-46981
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kyber: fix out of bounds access when preempted
__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and
passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx
for the current CPU again and uses that to get the corresponding Kyber
context in the passed hctx. However, the thread may be preempted between
the two calls to blk_mq_get_ctx(), and the ctx returned the second time
may no longer correspond to the passed hctx. This "works" accidentally
most of the time, but it can cause us to read garbage if the second ctx
came from an hctx with more ctx's than the first one (i.e., if
ctx->index_hw[hctx->type] > hctx->nr_ctx).
This manifested as this UBSAN array index out of bounds error reported
by Jakub:
UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9
index 13106 is out of range for type 'long unsigned int [128]'
Call Trace:
dump_stack+0xa4/0xe5
ubsan_epilogue+0x5/0x40
__ubsan_handle_out_of_bounds.cold.13+0x2a/0x34
queued_spin_lock_slowpath+0x476/0x480
do_raw_spin_lock+0x1c2/0x1d0
kyber_bio_merge+0x112/0x180
blk_mq_submit_bio+0x1f5/0x1100
submit_bio_noacct+0x7b0/0x870
submit_bio+0xc2/0x3a0
btrfs_map_bio+0x4f0/0x9d0
btrfs_submit_data_bio+0x24e/0x310
submit_one_bio+0x7f/0xb0
submit_extent_page+0xc4/0x440
__extent_writepage_io+0x2b8/0x5e0
__extent_writepage+0x28d/0x6e0
extent_write_cache_pages+0x4d7/0x7a0
extent_writepages+0xa2/0x110
do_writepages+0x8f/0x180
__writeback_single_inode+0x99/0x7f0
writeback_sb_inodes+0x34e/0x790
__writeback_inodes_wb+0x9e/0x120
wb_writeback+0x4d2/0x660
wb_workfn+0x64d/0xa10
process_one_work+0x53a/0xa80
worker_thread+0x69/0x5b0
kthread+0x20b/0x240
ret_from_fork+0x1f/0x30
Only Kyber uses the hctx, so fix it by passing the request_queue to
->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can
map the queues itself to avoid the mismatch.
CVE-2021-46984
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when cloning inline extents and using qgroups
There are a few exceptional cases where cloning an inline extent needs to
copy the inline extent data into a page of the destination inode.
When this happens, we end up starting a transaction while having a dirty
page for the destination inode and while having the range locked in the
destination's inode iotree too. Because when reserving metadata space
for a transaction we may need to flush existing delalloc in case there is
not enough free space, we have a mechanism in place to prevent a deadlock,
which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when
cloning inline extent and low on free metadata space").
However when using qgroups, a transaction also reserves metadata qgroup
space, which can also result in flushing delalloc in case there is not
enough available space at the moment. When this happens we deadlock, since
flushing delalloc requires locking the file range in the inode's iotree
and the range was already locked at the very beginning of the clone
operation, before attempting to start the transaction.
When this issue happens, stack traces like the following are reported:
[72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000
[72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)
[72747.556271] Call Trace:
[72747.556273] __schedule+0x296/0x760
[72747.556277] schedule+0x3c/0xa0
[72747.556279] io_schedule+0x12/0x40
[72747.556284] __lock_page+0x13c/0x280
[72747.556287] ? generic_file_readonly_mmap+0x70/0x70
[72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs]
[72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160
[72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]
[72747.556362] ? update_group_capacity+0x25/0x210
[72747.556366] ? cpumask_next_and+0x1a/0x20
[72747.556391] extent_writepages+0x44/0xa0 [btrfs]
[72747.556394] do_writepages+0x41/0xd0
[72747.556398] __writeback_single_inode+0x39/0x2a0
[72747.556403] writeback_sb_inodes+0x1ea/0x440
[72747.556407] __writeback_inodes_wb+0x5f/0xc0
[72747.556410] wb_writeback+0x235/0x2b0
[72747.556414] ? get_nr_inodes+0x35/0x50
[72747.556417] wb_workfn+0x354/0x490
[72747.556420] ? newidle_balance+0x2c5/0x3e0
[72747.556424] process_one_work+0x1aa/0x340
[72747.556426] worker_thread+0x30/0x390
[72747.556429] ? create_worker+0x1a0/0x1a0
[72747.556432] kthread+0x116/0x130
[72747.556435] ? kthread_park+0x80/0x80
[72747.556438] ret_from_fork+0x1f/0x30
[72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]
[72747.566961] Call Trace:
[72747.566964] __schedule+0x296/0x760
[72747.566968] ? finish_wait+0x80/0x80
[72747.566970] schedule+0x3c/0xa0
[72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]
[72747.566999] ? finish_wait+0x80/0x80
[72747.567024] lock_extent_bits+0x37/0x90 [btrfs]
[72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs]
[72747.567051] ? find_get_pages_range_tag+0x2cd/0x380
[72747.567076] __extent_writepage+0x203/0x320 [btrfs]
[72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs]
[72747.567106] ? update_load_avg+0x7e/0x5f0
[72747.567109] ? enqueue_entity+0xf4/0x6f0
[72747.567134] extent_writepages+0x44/0xa0 [btrfs]
[72747.567137] ? enqueue_task_fair+0x93/0x6f0
[72747.567140] do_writepages+0x41/0xd0
[72747.567144] __filemap_fdatawrite_range+0xc7/0x100
[72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs]
[72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs]
[72747.567200] process_one_work+0x1aa/0x340
[72747.567202] worker_thread+0x30/0x390
[72747.567205] ? create_worker+0x1a0/0x1a0
[72747.567208] kthread+0x116/0x130
[72747.567211] ? kthread_park+0x80/0x80
[72747.567214] ret_from_fork+0x1f/0x30
[72747.569686] task:fsstress state:D stack:
---truncated---
CVE-2021-46987
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: release page in error path to avoid BUG_ON
Consider the following sequence of events:
1. Userspace issues a UFFD ioctl, which ends up calling into
shmem_mfill_atomic_pte(). We successfully account the blocks, we
shmem_alloc_page(), but then the copy_from_user() fails. We return
-ENOENT. We don't release the page we allocated.
2. Our caller detects this error code, tries the copy_from_user() after
dropping the mmap_lock, and retries, calling back into
shmem_mfill_atomic_pte().
3. Meanwhile, let's say another process filled up the tmpfs being used.
4. So shmem_mfill_atomic_pte() fails to account blocks this time, and
immediately returns - without releasing the page.
This triggers a BUG_ON in our caller, which asserts that the page
should always be consumed, unless -ENOENT is returned.
To fix this, detect if we have such a "dangling" page when accounting
fails, and if so, release it before returning.
CVE-2021-46988
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s: Fix crashes when toggling entry flush barrier
The entry flush mitigation can be enabled/disabled at runtime via a
debugfs file (entry_flush), which causes the kernel to patch itself to
enable/disable the relevant mitigations.
However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are active. For example the following
crash:
sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20
Shows that we returned to userspace with a corrupted LR that points into
the kernel, due to executing the partially patched call to the fallback
entry flush (ie. we missed the LR restore).
Fix it by doing the patching under stop machine. The CPUs that aren't
doing the patching will be spinning in the core of the stop machine
logic. That is currently sufficient for our purposes, because none of
the patching we do is to that code or anywhere in the vicinity.
CVE-2021-46990
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix use-after-free in i40e_client_subtask()
Currently the call to i40e_client_del_instance frees the object
pf->cinst, however pf->cinst->lan_info is being accessed after
the free. Fix this by adding the missing return.
Addresses-Coverity: ("Read from pointer after free")
CVE-2021-46991
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: avoid overflows in nft_hash_buckets()
Number of buckets being stored in 32bit variables, we have to
ensure that no overflows occur in nft_hash_buckets()
syzbot injected a size == 0x40000000 and reported:
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
__ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327
__roundup_pow_of_two include/linux/log2.h:57 [inline]
nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline]
nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652
nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline]
nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322
nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488
nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline]
nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630
netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
CVE-2021-46992
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ethernet:enic: Fix a use after free bug in enic_hard_start_xmit
In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside
enic_queue_wq_skb, if some error happens, the skb will be freed
by dev_kfree_skb(skb). But the freed skb is still used in
skb_tx_timestamp(skb).
My patch makes enic_queue_wq_skb() return error and goto spin_unlock()
incase of error. The solution is provided by Govind.
See https://lkml.org/lkml/2021/4/30/961.
CVE-2021-46998
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook
The commit 1879445dfa7b ("perf/core: Set event's default
::overflow_handler()") set a default event->overflow_handler in
perf_event_alloc(), and replace the check event->overflow_handler with
is_default_overflow_handler(), but one is missing.
Currently, the bp->overflow_handler can not be NULL. As a result,
enable_single_step() is always not invoked.
Comments from Zhen Lei:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/
CVE-2021-47006
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).
If some error happens in emac_tx_fill_tpd(), the skb will be freed via
dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().
But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).
As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len,
thus my patch assigns skb->len to 'len' before the possible free and
use 'len' instead of skb->len later.
CVE-2021-47013
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix RX consumer index logic in the error path.
In bnxt_rx_pkt(), the RX buffers are expected to complete in order.
If the RX consumer index indicates an out of order buffer completion,
it means we are hitting a hardware bug and the driver will abort all
remaining RX packets and reset the RX ring. The RX consumer index
that we pass to bnxt_discard_rx() is not correct. We should be
passing the current index (tmp_raw_cons) instead of the old index
(raw_cons). This bug can cause us to be at the wrong index when
trying to abort the next RX packet. It can crash like this:
#0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007
#1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232
#2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e
#3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978
#4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0
#5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e
#6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24
#7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e
#8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12
#9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5
[exception RIP: bnxt_rx_pkt+237]
RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213
RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000
RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000
RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d
R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0
R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
CVE-2021-47015
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: free queued packets when closing socket
As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
("vsock/virtio: free packets during the socket release"), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.
To avoid future issues, let's use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().
[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9
CVE-2021-47024
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s: Fix pte update for kernel memory on radix
When adding a PTE a ptesync is needed to order the update of the PTE
with subsequent accesses otherwise a spurious fault may be raised.
radix__set_pte_at() does not do this for performance gains. For
non-kernel memory this is not an issue as any faults of this kind are
corrected by the page fault handler. For kernel memory these faults
are not handled. The current solution is that there is a ptesync in
flush_cache_vmap() which should be called when mapping from the
vmalloc region.
However, map_kernel_page() does not call flush_cache_vmap(). This is
troublesome in particular for code patching with Strict RWX on radix.
In do_patch_instruction() the page frame that contains the instruction
to be patched is mapped and then immediately patched. With no ordering
or synchronization between setting up the PTE and writing to the page
it is possible for faults.
As the code patching is done using __put_user_asm_goto() the resulting
fault is obscured - but using a normal store instead it can be seen:
BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c
Faulting instruction address: 0xc00000000008bd74
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: nop_module(PO+) [last unloaded: nop_module]
CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43
NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810
REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER: 00000000
CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1
This results in the kind of issue reported here:
https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/
Chris Riedl suggested a reliable way to reproduce the issue:
$ mount -t debugfs none /sys/kernel/debug
$ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) &
Turning ftrace on and off does a large amount of code patching which
in usually less then 5min will crash giving a trace like:
ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000)
------------[ ftrace bug ]------------
ftrace failed to modify
[<c000000000bf8e5c>] napi_busy_loop+0xc/0x390
actual: 11:3b:47:4b
Setting ftrace call site to call ftrace function
ftrace record flags: 80000001
(1)
expected tramp: c00000000006c96c
------------[ cut here ]------------
WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8
Modules linked in: nop_module(PO-) [last unloaded: nop_module]
CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1
NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0
REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a)
MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000
CFAR: c0000000001a9c98 IRQMASK: 0
GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022
GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8
GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118
GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000
GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008
GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8
GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020
GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0
NIP ftrace_bug+0x28c/0x2e8
LR ftrace_bug+0x288/0x2e8
Call T
---truncated---
CVE-2021-47034
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()
It is possible to call lpfc_issue_els_plogi() passing a did for which no
matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a
null pointer to a lpfc_nodelist structure resulting in a null pointer
dereference.
Fix by returning an error status if no valid ndlp is found. Fix up comments
regarding ndlp reference counting.
CVE-2021-47045
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Use after free in __vmbus_open()
The "open_info" variable is added to the &vmbus_connection.chn_msg_list,
but the error handling frees "open_info" without removing it from the
list. This will result in a use after free. First remove it from the
list, and then free it.
CVE-2021-47049
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bus: qcom: Put child node before return
Put child node before return to fix potential reference count leak.
Generally, the reference count of child is incremented and decremented
automatically in the macro for_each_available_child_of_node() and should
be decremented manually if the loop is broken in loop body.
CVE-2021-47054
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mtd: require write permissions for locking and badblock ioctls
MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require
write permission. Depending on the hardware MEMLOCK might even be
write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK
is always write-once.
MEMSETBADBLOCK modifies the bad block table.
CVE-2021-47055
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init
ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()
before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the
vf2pf_lock is initialized in adf_dev_init(), which can fail and when it
fail, the vf2pf_lock is either not initialized or destroyed, a subsequent
use of vf2pf_lock will cause issue.
To fix this issue, only set this flag if adf_dev_init() returns 0.
[ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0
[ 7.180345] Call Trace:
[ 7.182576] mutex_lock+0xc9/0xd0
[ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat]
[ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat]
[ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat]
[ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf]
CVE-2021-47056
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm: bridge/panel: Cleanup connector on bridge detach
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector will be long gone. Therefore, the
connector must be cleaned up when the bridge is detached to avoid
use-after-free conditions.
v2: Cleanup connector only if it was created
v3: Add FIXME
v4: (Use connector->dev) directly in if() block
CVE-2021-47063
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Fix another memory leak in error handling paths
Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
function is never freed in the error handling path.
Add the missing 'vmbus_free_ring()' call.
Note that it is already freed in the .remove function.
CVE-2021-47070
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Fix a memory leak in error handling paths
If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be
updated and 'hv_uio_cleanup()' in the error handling path will not be
able to free the corresponding buffer.
In such a case, we need to free the buffer explicitly.
CVE-2021-47071
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios
init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems
where the Dell WMI interface is supported. While exit_dell_smbios_wmi()
unregisters it unconditionally, this leads to the following oops:
[ 175.722921] ------------[ cut here ]------------
[ 175.722925] Unexpected driver unregister!
[ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40
...
[ 175.723089] Call Trace:
[ 175.723094] cleanup_module+0x5/0xedd [dell_smbios]
...
[ 175.723148] ---[ end trace 064c34e1ad49509d ]---
Make the unregister happen on the same condition the register happens
to fix this.
CVE-2021-47073
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-loop: fix memory leak in nvme_loop_create_ctrl()
When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl()
fails, the loop ctrl should be freed before jumping to the "out" label.
CVE-2021-47074
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Return CQE error if invalid lkey was supplied
RXE is missing update of WQE status in LOCAL_WRITE failures. This caused
the following kernel panic if someone sent an atomic operation with an
explicitly wrong lkey.
[leonro@vm ~]$ mkt test
test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ...
WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe]
Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core
CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe]
Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff
RSP: 0018:ffff8880158af090 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652
RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210
RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b
R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8
R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c
FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
rxe_do_task+0x130/0x230 [rdma_rxe]
rxe_rcv+0xb11/0x1df0 [rdma_rxe]
rxe_loopback+0x157/0x1e0 [rdma_rxe]
rxe_responder+0x5532/0x7620 [rdma_rxe]
rxe_do_task+0x130/0x230 [rdma_rxe]
rxe_rcv+0x9c8/0x1df0 [rdma_rxe]
rxe_loopback+0x157/0x1e0 [rdma_rxe]
rxe_requester+0x1efd/0x58c0 [rdma_rxe]
rxe_do_task+0x130/0x230 [rdma_rxe]
rxe_post_send+0x998/0x1860 [rdma_rxe]
ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs]
ib_uverbs_write+0x847/0xc80 [ib_uverbs]
vfs_write+0x1c5/0x840
ksys_write+0x176/0x1d0
do_syscall_64+0x3f/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-47076
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Add pointer checks in qedf_update_link_speed()
The following trace was observed:
[ 14.042059] Call Trace:
[ 14.042061] <IRQ>
[ 14.042068] qedf_link_update+0x144/0x1f0 [qedf]
[ 14.042117] qed_link_update+0x5c/0x80 [qed]
[ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed]
[ 14.042155] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042170] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042186] ? qed_rd+0x13/0x40 [qed]
[ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed]
[ 14.042221] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed]
[ 14.042245] tasklet_action_common.isra.14+0x5a/0x100
[ 14.042250] __do_softirq+0xe4/0x2f8
[ 14.042253] irq_exit+0xf7/0x100
[ 14.042255] do_IRQ+0x7f/0xd0
[ 14.042257] common_interrupt+0xf/0xf
[ 14.042259] </IRQ>
API qedf_link_update() is getting called from QED but by that time
shost_data is not initialised. This results in a NULL pointer dereference
when we try to dereference shost_data while updating supported_speeds.
Add a NULL pointer check before dereferencing shost_data.
CVE-2021-47077
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Clear all QP fields if creation failed
rxe_qp_do_cleanup() relies on valid pointer values in QP for the properly
created ones, but in case rxe_qp_from_init() failed it was filled with
garbage and caused tot the following error.
refcount_t: underflow; use-after-free.
WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28
Modules linked in:
CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28
Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55
RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67
RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800
R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000
FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__refcount_sub_and_test include/linux/refcount.h:283 [inline]
__refcount_dec_and_test include/linux/refcount.h:315 [inline]
refcount_dec_and_test include/linux/refcount.h:333 [inline]
kref_put include/linux/kref.h:64 [inline]
rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805
execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327
rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391
kref_put include/linux/kref.h:65 [inline]
rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425
_ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline]
ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231
ib_create_qp include/rdma/ib_verbs.h:3644 [inline]
create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920
ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline]
ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092
add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717
enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331
ib_register_device drivers/infiniband/core/device.c:1413 [inline]
ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365
rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147
rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247
rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503
rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline]
rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250
nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555
rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195
rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259
netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0
---truncated---
CVE-2021-47078
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module
Hi,
When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
the system crashed.
The log as follows:
[ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a
[ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0
[ 141.087464] Oops: 0010 [#1] SMP NOPTI
[ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47
[ 141.088009] Workqueue: events 0xffffffffc09b3a40
[ 141.088009] RIP: 0010:0xffffffffc09b3a5a
[ 141.088009] Code: Bad RIP value.
[ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246
[ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000
[ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1
[ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700
[ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8
[ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
[ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0
[ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 141.088009] PKRU: 55555554
[ 141.088009] Call Trace:
[ 141.088009] ? process_one_work+0x195/0x390
[ 141.088009] ? worker_thread+0x30/0x390
[ 141.088009] ? process_one_work+0x390/0x390
[ 141.088009] ? kthread+0x10d/0x130
[ 141.088009] ? kthread_flush_work_fn+0x10/0x10
[ 141.088009] ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a
[ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0
[ 200.223464] Oops: 0010 [#1] SMP NOPTI
[ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46
[ 200.224008] Workqueue: events 0xffffffffc0b28a40
[ 200.224008] RIP: 0010:0xffffffffc0b28a5a
[ 200.224008] Code: Bad RIP value.
[ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246
[ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000
[ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5
[ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700
[ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8
[ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000
[ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0
[ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 200.224008] PKRU: 55555554
[ 200.224008] Call Trace:
[ 200.224008] ? process_one_work+0x195/0x390
[ 200.224008] ? worker_thread+0x30/0x390
[ 200.224008] ? process_one_work+0x390/0x390
[ 200.224008] ? kthread+0x10d/0x130
[ 200.224008] ? kthread_flush_work_fn+0x10/0x10
[ 200.224008] ? ret_from_fork+0x35/0x40
[ 200.224008] kernel fault(0x1) notification starting on CPU 63
[ 200.224008] kernel fault(0x1) notification finished on CPU 63
[ 200.224008] CR2: ffffffffc0b28a5a
[ 200.224008] ---[ end trace c82a412d93f57412 ]---
The reason is as follows:
T1: rmmod ipmi_si.
->ipmi_unregister_smi()
-> ipmi_bmc_unregister()
-> __ipmi_bmc_unregister()
-> kref_put(&bmc->usecount, cleanup_bmc_device);
-> schedule_work(&bmc->remove_work);
T2: rmmod ipmi_msghandl
---truncated---
CVE-2021-47100
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
asix: fix uninit-value in asix_mdio_read()
asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
smsr will be uninitialized.
Fail log:
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
CVE-2021-47101
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
inet: fully convert sk->sk_rx_dst to RCU rules
syzbot reported various issues around early demux,
one being included in this changelog [1]
sk->sk_rx_dst is using RCU protection without clearly
documenting it.
And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv()
are not following standard RCU rules.
[a] dst_release(dst);
[b] sk->sk_rx_dst = NULL;
They look wrong because a delete operation of RCU protected
pointer is supposed to clear the pointer before
the call_rcu()/synchronize_rcu() guarding actual memory freeing.
In some cases indeed, dst could be freed before [b] is done.
We could cheat by clearing sk_rx_dst before calling
dst_release(), but this seems the right time to stick
to standard RCU annotations and debugging facilities.
[1]
BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline]
BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204
CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247
__kasan_report mm/kasan/report.c:433 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
dst_check include/net/dst.h:470 [inline]
tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
ip_rcv_finish_core.constprop.0+0x15de/0x1e80 net/ipv4/ip_input.c:340
ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583
ip_sublist_rcv net/ipv4/ip_input.c:609 [inline]
ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644
__netif_receive_skb_list_ptype net/core/dev.c:5508 [inline]
__netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556
__netif_receive_skb_list net/core/dev.c:5608 [inline]
netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699
gro_normal_list net/core/dev.c:5853 [inline]
gro_normal_list net/core/dev.c:5849 [inline]
napi_complete_done+0x1f1/0x880 net/core/dev.c:6590
virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline]
virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557
__napi_poll+0xaf/0x440 net/core/dev.c:7023
napi_poll net/core/dev.c:7090 [inline]
net_rx_action+0x801/0xb40 net/core/dev.c:7177
__do_softirq+0x29b/0x9c2 kernel/softirq.c:558
invoke_softirq kernel/softirq.c:432 [inline]
__irq_exit_rcu+0x123/0x180 kernel/softirq.c:637
irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
common_interrupt+0x52/0xc0 arch/x86/kernel/irq.c:240
asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629
RIP: 0033:0x7f5e972bfd57
Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e <48> 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73
RSP: 002b:00007fff8a413210 EFLAGS: 00000283
RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45
RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45
RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9
R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0
R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019
</TASK>
Allocated by task 13:
kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:434 [inline]
__kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:467
kasan_slab_alloc include/linux/kasan.h:259 [inline]
slab_post_alloc_hook mm/slab.h:519 [inline]
slab_alloc_node mm/slub.c:3234 [inline]
slab_alloc mm/slub.c:3242 [inline]
kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247
dst_alloc+0x146/0x1f0 net/core/dst.c:92
rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613
ip_route_input_slow+0x1817/0x3a20 net/ipv4/route.c:234
---truncated---
CVE-2021-47103
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()
The wrong goto label was used for the error case and missed cleanup of the
pkt allocation.
Addresses-Coverity-ID: 1493352 ("Resource leak")
CVE-2021-47104
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/kvm: Disable kvmclock on all CPUs on shutdown
Currenly, we disable kvmclock from machine_shutdown() hook and this
only happens for boot CPU. We need to disable it for all CPUs to
guard against memory corruption e.g. on restore from hibernate.
Note, writing '0' to kvmclock MSR doesn't clear memory location, it
just prevents hypervisor from updating the location so for the short
while after write and while CPU is still alive, the clock remains usable
and correct so we don't need to switch to some other clocksource.
CVE-2021-47110
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/kvm: Teardown PV features on boot CPU as well
Various PV features (Async PF, PV EOI, steal time) work through memory
shared with hypervisor and when we restore from hibernation we must
properly teardown all these features to make sure hypervisor doesn't
write to stale locations after we jump to the previously hibernated kernel
(which can try to place anything there). For secondary CPUs the job is
already done by kvm_cpu_down_prepare(), register syscore ops to do
the same for boot CPU.
CVE-2021-47112
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: abort in rename_exchange if we fail to insert the second ref
Error injection stress uncovered a problem where we'd leave a dangling
inode ref if we failed during a rename_exchange. This happens because
we insert the inode ref for one side of the rename, and then for the
other side. If this second inode ref insert fails we'll leave the first
one dangling and leave a corrupt file system behind. Fix this by
aborting if we did the insert for the first inode ref.
CVE-2021-47113
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption by fallocate
When fallocate punches holes out of inode size, if original isize is in
the middle of last cluster, then the part from isize to the end of the
cluster will be zeroed with buffer write, at that time isize is not yet
updated to match the new size, if writeback is kicked in, it will invoke
ocfs2_writepage()->block_write_full_page() where the pages out of inode
size will be dropped. That will cause file corruption. Fix this by
zero out eof blocks when extending the inode size.
Running the following command with qemu-image 4.2.1 can get a corrupted
coverted image file easily.
qemu-img convert -p -t none -T none -f qcow2 $qcow_image \
-O qcow2 -o compat=1.1 $qcow_image.conv
The usage of fallocate in qemu is like this, it first punches holes out
of inode size, then extend the inode size.
fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0
fallocate(11, 0, 2276196352, 65536) = 0
v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html
v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/
CVE-2021-47114
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed
We got follow bug_on when run fsstress with injecting IO fault:
[130747.323114] kernel BUG at fs/ext4/extents_status.c:762!
[130747.323117] Internal error: Oops - BUG: 0 [#1] SMP
......
[130747.334329] Call trace:
[130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4]
[130747.334975] ext4_cache_extents+0x64/0xe8 [ext4]
[130747.335368] ext4_find_extent+0x300/0x330 [ext4]
[130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4]
[130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4]
[130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4]
[130747.336995] ext4_readpage+0x54/0x100 [ext4]
[130747.337359] generic_file_buffered_read+0x410/0xae8
[130747.337767] generic_file_read_iter+0x114/0x190
[130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4]
[130747.338556] __vfs_read+0x11c/0x188
[130747.338851] vfs_read+0x94/0x150
[130747.339110] ksys_read+0x74/0xf0
This patch's modification is according to Jan Kara's suggestion in:
https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/
"I see. Now I understand your patch. Honestly, seeing how fragile is trying
to fix extent tree after split has failed in the middle, I would probably
go even further and make sure we fix the tree properly in case of ENOSPC
and EDQUOT (those are easily user triggerable). Anything else indicates a
HW problem or fs corruption so I'd rather leave the extent tree as is and
don't try to fix it (which also means we will not create overlapping
extents)."
CVE-2021-47117
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pid: take a reference when initializing `cad_pid`
During boot, kernel_init_freeable() initializes `cad_pid` to the init
task's struct pid. Later on, we may change `cad_pid` via a sysctl, and
when this happens proc_do_cad_pid() will increment the refcount on the
new pid via get_pid(), and will decrement the refcount on the old pid
via put_pid(). As we never called get_pid() when we initialized
`cad_pid`, we decrement a reference we never incremented, can therefore
free the init task's struct pid early. As there can be dangling
references to the struct pid, we can later encounter a use-after-free
(e.g. when delivering signals).
This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to
have been around since the conversion of `cad_pid` to struct pid in
commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the
pre-KASAN stone age of v2.6.19.
Fix this by getting a reference to the init task's struct pid when we
assign it to `cad_pid`.
Full KASAN splat below.
==================================================================
BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline]
BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273
CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1
Hardware name: linux,dummy-virt (DT)
Call trace:
ns_of_pid include/linux/pid.h:153 [inline]
task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
do_notify_parent+0x308/0xe60 kernel/signal.c:1950
exit_notify kernel/exit.c:682 [inline]
do_exit+0x2334/0x2bd0 kernel/exit.c:845
do_group_exit+0x108/0x2c8 kernel/exit.c:922
get_signal+0x4e4/0x2a88 kernel/signal.c:2781
do_signal arch/arm64/kernel/signal.c:882 [inline]
do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936
work_pending+0xc/0x2dc
Allocated by task 0:
slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516
slab_alloc_node mm/slub.c:2907 [inline]
slab_alloc mm/slub.c:2915 [inline]
kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920
alloc_pid+0xdc/0xc00 kernel/pid.c:180
copy_process+0x2794/0x5e18 kernel/fork.c:2129
kernel_clone+0x194/0x13c8 kernel/fork.c:2500
kernel_thread+0xd4/0x110 kernel/fork.c:2552
rest_init+0x44/0x4a0 init/main.c:687
arch_call_rest_init+0x1c/0x28
start_kernel+0x520/0x554 init/main.c:1064
0x0
Freed by task 270:
slab_free_hook mm/slub.c:1562 [inline]
slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600
slab_free mm/slub.c:3161 [inline]
kmem_cache_free+0x224/0x8e0 mm/slub.c:3177
put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114
put_pid+0x30/0x48 kernel/pid.c:109
proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401
proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591
proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617
call_write_iter include/linux/fs.h:1977 [inline]
new_sync_write+0x3ac/0x510 fs/read_write.c:518
vfs_write fs/read_write.c:605 [inline]
vfs_write+0x9c4/0x1018 fs/read_write.c:585
ksys_write+0x124/0x240 fs/read_write.c:658
__do_sys_write fs/read_write.c:670 [inline]
__se_sys_write fs/read_write.c:667 [inline]
__arm64_sys_write+0x78/0xb0 fs/read_write.c:667
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]
el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129
do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168
el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416
el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432
el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701
The buggy address belongs to the object at ffff23794dda0000
which belongs to the cache pid of size 224
The buggy address is located 4 bytes inside of
224-byte region [ff
---truncated---
CVE-2021-47118
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix memory leak in ext4_fill_super
Buffer head references must be released before calling kill_bdev();
otherwise the buffer head (and its page referenced by b_data) will not
be freed by kill_bdev, and subsequently that bh will be leaked.
If blocksizes differ, sb_set_blocksize() will kill current buffers and
page cache by using kill_bdev(). And then super block will be reread
again but using correct blocksize this time. sb_set_blocksize() didn't
fully free superblock page and buffer head, and being busy, they were
not freed and instead leaked.
This can easily be reproduced by calling an infinite loop of:
systemctl start <ext4_on_lvm>.mount, and
systemctl stop <ext4_on_lvm>.mount
... since systemd creates a cgroup for each slice which it mounts, and
the bh leak get amplified by a dying memory cgroup that also never
gets freed, and memory consumption is much more easily noticed.
CVE-2021-47119
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Fix use-after-free after the TLS device goes down and up
When a netdev with active TLS offload goes down, tls_device_down is
called to stop the offload and tear down the TLS context. However, the
socket stays alive, and it still points to the TLS context, which is now
deallocated. If a netdev goes up, while the connection is still active,
and the data flow resumes after a number of TCP retransmissions, it will
lead to a use-after-free of the TLS context.
This commit addresses this bug by keeping the context alive until its
normal destruction, and implements the necessary fallbacks, so that the
connection can resume in software (non-offloaded) kTLS mode.
On the TX side tls_sw_fallback is used to encrypt all packets. The RX
side already has all the necessary fallbacks, because receiving
non-decrypted packets is supported. The thing needed on the RX side is
to block resync requests, which are normally produced after receiving
non-decrypted packets.
The necessary synchronization is implemented for a graceful teardown:
first the fallbacks are deployed, then the driver resources are released
(it used to be possible to have a tls_dev_resync after tls_dev_del).
A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback
mode. It's used to skip the RX resync logic completely, as it becomes
useless, and some objects may be released (for example, resync_async,
which is allocated and freed by the driver).
CVE-2021-47131
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
cxgb4: avoid accessing registers when clearing filters
Hardware register having the server TID base can contain
invalid values when adapter is in bad state (for example,
due to AER fatal error). Reading these invalid values in the
register can lead to out-of-bound memory access. So, fix
by using the saved server TID base when clearing filters.
CVE-2021-47138
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gve: Add NULL pointer checks when freeing irqs.
When freeing notification blocks, we index priv->msix_vectors.
If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors)
this could lead to a NULL pointer dereference if the driver is unloaded.
CVE-2021-47141
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a use-after-free
looks like we forget to set ttm->sg to NULL.
Hit panic below
[ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[ 1235.989074] Call Trace:
[ 1235.991751] sg_free_table+0x17/0x20
[ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu]
[ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu]
[ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm]
[ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm]
[ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm]
[ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm]
[ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu]
[ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu]
[ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu]
[ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu]
CVE-2021-47142
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: remove device from smcd_dev_list after failed device_add()
If the device_add() for a smcd_dev fails, there's no cleanup step that
rolls back the earlier list_add(). The device subsequently gets freed,
and we end up with a corrupted list.
Add some error handling that removes the device from the list.
CVE-2021-47143
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not BUG_ON in link_to_fixup_dir
While doing error injection testing I got the following panic
kernel BUG at fs/btrfs/tree-log.c:1862!
invalid opcode: 0000 [#1] SMP NOPTI
CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
RIP: 0010:link_to_fixup_dir+0xd5/0xe0
RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216
RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0
RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000
RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001
R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800
R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065
FS: 00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0
Call Trace:
replay_one_buffer+0x409/0x470
? btree_read_extent_buffer_pages+0xd0/0x110
walk_up_log_tree+0x157/0x1e0
walk_log_tree+0xa6/0x1d0
btrfs_recover_log_trees+0x1da/0x360
? replay_one_extent+0x7b0/0x7b0
open_ctree+0x1486/0x1720
btrfs_mount_root.cold+0x12/0xea
? __kmalloc_track_caller+0x12f/0x240
legacy_get_tree+0x24/0x40
vfs_get_tree+0x22/0xb0
vfs_kern_mount.part.0+0x71/0xb0
btrfs_mount+0x10d/0x380
? vfs_parse_fs_string+0x4d/0x90
legacy_get_tree+0x24/0x40
vfs_get_tree+0x22/0xb0
path_mount+0x433/0xa10
__x64_sys_mount+0xe3/0x120
do_syscall_64+0x3d/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
We can get -EIO or any number of legitimate errors from
btrfs_search_slot(), panicing here is not the appropriate response. The
error path for this code handles errors properly, simply return the
error.
CVE-2021-47145
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mld: fix panic in mld_newpack()
mld_newpack() doesn't allow to allocate high order page,
only order-0 allocation is allowed.
If headroom size is too large, a kernel panic could occur in skb_put().
Test commands:
ip netns del A
ip netns del B
ip netns add A
ip netns add B
ip link add veth0 type veth peer name veth1
ip link set veth0 netns A
ip link set veth1 netns B
ip netns exec A ip link set lo up
ip netns exec A ip link set veth0 up
ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0
ip netns exec B ip link set lo up
ip netns exec B ip link set veth1 up
ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1
for i in {1..99}
do
let A=$i-1
ip netns exec A ip link add ip6gre$i type ip6gre \
local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100
ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i
ip netns exec A ip link set ip6gre$i up
ip netns exec B ip link add ip6gre$i type ip6gre \
local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100
ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i
ip netns exec B ip link set ip6gre$i up
done
Splat looks like:
kernel BUG at net/core/skbuff.c:110!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:skb_panic+0x15d/0x15f
Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83
41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89
34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20
RSP: 0018:ffff88810091f820 EFLAGS: 00010282
RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000
RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb
RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031
R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028
R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0
FS: 0000000000000000(0000) GS:ffff888117c00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
skb_put.cold.104+0x22/0x22
ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
? rcu_read_lock_sched_held+0x91/0xc0
mld_newpack+0x398/0x8f0
? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600
? lock_contended+0xc40/0xc40
add_grhead.isra.33+0x280/0x380
add_grec+0x5ca/0xff0
? mld_sendpack+0xf40/0xf40
? lock_downgrade+0x690/0x690
mld_send_initial_cr.part.34+0xb9/0x180
ipv6_mc_dad_complete+0x15d/0x1b0
addrconf_dad_completed+0x8d2/0xbb0
? lock_downgrade+0x690/0x690
? addrconf_rs_timer+0x660/0x660
? addrconf_dad_work+0x73c/0x10e0
addrconf_dad_work+0x73c/0x10e0
Allowing high order page allocation could fix this problem.
CVE-2021-47146
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fujitsu: fix potential null-ptr-deref
In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer
deref. To fix this, check the return value of ioremap and return -1
to the caller in case of failure.
CVE-2021-47149
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fec: fix the potential memory leak in fec_enet_init()
If the memory allocated for cbd_base is failed, it should
free the memory allocated for the queues, otherwise it causes
memory leak.
And if the memory allocated for the queues is failed, it can
return error directly.
CVE-2021-47150
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: i801: Don't generate an interrupt on bus reset
Now that the i2c-i801 driver supports interrupts, setting the KILL bit
in a attempt to recover from a timed out transaction triggers an
interrupt. Unfortunately, the interrupt handler (i801_isr) is not
prepared for this situation and will try to process the interrupt as
if it was signaling the end of a successful transaction. In the case
of a block transaction, this can result in an out-of-range memory
access.
This condition was reproduced several times by syzbot:
https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e
https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e
https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e
https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb
https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a
https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79
So disable interrupts while trying to reset the bus. Interrupts will
be enabled again for the following transaction.
CVE-2021-47153
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-fsl-dspi: Fix a resource leak in an error handling path
'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the
error handling path of the probe function, as already done in the remove
function
CVE-2021-47161
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: skb_linearize the head skb when reassembling msgs
It's not a good idea to append the frag skb to a skb's frag_list if
the frag_list already has skbs from elsewhere, such as this skb was
created by pskb_copy() where the frag_list was cloned (all the skbs
in it were skb_get'ed) and shared by multiple skbs.
However, the new appended frag skb should have been only seen by the
current skb. Otherwise, it will cause use after free crashes as this
appended frag skb are seen by multiple skbs but it only got skb_get
called once.
The same thing happens with a skb updated by pskb_may_pull() with a
skb_cloned skb. Li Shuang has reported quite a few crashes caused
by this when doing testing over macvlan devices:
[] kernel BUG at net/core/skbuff.c:1970!
[] Call Trace:
[] skb_clone+0x4d/0xb0
[] macvlan_broadcast+0xd8/0x160 [macvlan]
[] macvlan_process_broadcast+0x148/0x150 [macvlan]
[] process_one_work+0x1a7/0x360
[] worker_thread+0x30/0x390
[] kernel BUG at mm/usercopy.c:102!
[] Call Trace:
[] __check_heap_object+0xd3/0x100
[] __check_object_size+0xff/0x16b
[] simple_copy_to_iter+0x1c/0x30
[] __skb_datagram_iter+0x7d/0x310
[] __skb_datagram_iter+0x2a5/0x310
[] skb_copy_datagram_iter+0x3b/0x90
[] tipc_recvmsg+0x14a/0x3a0 [tipc]
[] ____sys_recvmsg+0x91/0x150
[] ___sys_recvmsg+0x7b/0xc0
[] kernel BUG at mm/slub.c:305!
[] Call Trace:
[] <IRQ>
[] kmem_cache_free+0x3ff/0x400
[] __netif_receive_skb_core+0x12c/0xc40
[] ? kmem_cache_alloc+0x12e/0x270
[] netif_receive_skb_internal+0x3d/0xb0
[] ? get_rx_page_info+0x8e/0xa0 [be2net]
[] be_poll+0x6ef/0xd00 [be2net]
[] ? irq_exit+0x4f/0x100
[] net_rx_action+0x149/0x3b0
...
This patch is to fix it by linearizing the head skb if it has frag_list
set in tipc_buf_append(). Note that we choose to do this before calling
skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can
not just drop the frag_list either as the early time.
CVE-2021-47162
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: wait and exit until all work queues are done
On some host, a crash could be triggered simply by repeating these
commands several times:
# modprobe tipc
# tipc bearer enable media udp name UDP1 localip 127.0.0.1
# rmmod tipc
[] BUG: unable to handle kernel paging request at ffffffffc096bb00
[] Workqueue: events 0xffffffffc096bb00
[] Call Trace:
[] ? process_one_work+0x1a7/0x360
[] ? worker_thread+0x30/0x390
[] ? create_worker+0x1a0/0x1a0
[] ? kthread+0x116/0x130
[] ? kthread_flush_work_fn+0x10/0x10
[] ? ret_from_fork+0x35/0x40
When removing the TIPC module, the UDP tunnel sock will be delayed to
release in a work queue as sock_release() can't be done in rtnl_lock().
If the work queue is schedule to run after the TIPC module is removed,
kernel will crash as the work queue function cleanup_beareri() code no
longer exists when trying to invoke it.
To fix it, this patch introduce a member wq_count in tipc_net to track
the numbers of work queues in schedule, and wait and exit until all
work queues are done in tipc_exit_net().
CVE-2021-47163
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/meson: fix shutdown crash when component not probed
When main component is not probed, by example when the dw-hdmi module is
not loaded yet or in probe defer, the following crash appears on shutdown:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
...
pc : meson_drv_shutdown+0x24/0x50
lr : platform_drv_shutdown+0x20/0x30
...
Call trace:
meson_drv_shutdown+0x24/0x50
platform_drv_shutdown+0x20/0x30
device_shutdown+0x158/0x360
kernel_restart_prepare+0x38/0x48
kernel_restart+0x18/0x68
__do_sys_reboot+0x224/0x250
__arm64_sys_reboot+0x24/0x30
...
Simply check if the priv struct has been allocated before using it.
CVE-2021-47165
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce()
The value of mirror->pg_bytes_written should only be updated after a
successful attempt to flush out the requests on the list.
CVE-2021-47166
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix an Oopsable condition in __nfs_pageio_add_request()
Ensure that nfs_pageio_error_cleanup() resets the mirror array contents,
so that the structure reflects the fact that it is now empty.
Also change the test in nfs_pageio_do_add_request() to be more robust by
checking whether or not the list is empty rather than relying on the
value of pg_count.
CVE-2021-47167
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFS: fix an incorrect limit in filelayout_decode_layout()
The "sizeof(struct nfs_fh)" is two bytes too large and could lead to
memory corruption. It should be NFS_MAXFHSIZE because that's the size
of the ->data[] buffer.
I reversed the size of the arguments to put the variable on the left.
CVE-2021-47168
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'
In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls
'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the
firmware don't exists, function just return without initializing ports
of 'rp2_card'. But now the interrupt handler function has been
registered, and when an interrupt comes, 'rp2_uart_interrupt' may access
those ports then causing NULL pointer dereference or other bugs.
Because the driver does some initialization work in 'rp2_fw_cb', in
order to make the driver ready to handle interrupts, 'request_firmware'
should be used instead of asynchronous 'request_firmware_nowait'.
This report reveals it:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xec/0x156 lib/dump_stack.c:118
assign_lock_key kernel/locking/lockdep.c:727 [inline]
register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753
__lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303
lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline]
rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493
rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504
__handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
</IRQ>
RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8
8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90
90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200
RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840
R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002
R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]
RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:
493
Co
---truncated---
CVE-2021-47169
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: usbfs: Don't WARN about excessively large memory allocations
Syzbot found that the kernel generates a WARNing if the user tries to
submit a bulk transfer through usbfs with a buffer that is way too
large. This isn't a bug in the kernel; it's merely an invalid request
from the user and the usbfs code does handle it correctly.
In theory the same thing can happen with async transfers, or with the
packet descriptor table for isochronous transfers.
To prevent the MM subsystem from complaining about these bad
allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
for these buffers.
CVE-2021-47170
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: fix memory leak in smsc75xx_bind
Syzbot reported memory leak in smsc75xx_bind().
The problem was is non-freed memory in case of
errors after memory allocation.
backtrace:
[<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline]
[<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline]
[<ffffffff84245b62>] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460
[<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728
CVE-2021-47171
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
misc/uss720: fix memory leak in uss720_probe
uss720_probe forgets to decrease the refcount of usbdev in uss720_probe.
Fix this by decreasing the refcount of usbdev by usb_put_dev.
BUG: memory leak
unreferenced object 0xffff888101113800 (size 2048):
comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s)
hex dump (first 32 bytes):
ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1...........
00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................
backtrace:
[<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline]
[<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline]
[<ffffffff82b8e822>] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582
[<ffffffff82b98441>] hub_port_connect drivers/usb/core/hub.c:5129 [inline]
[<ffffffff82b98441>] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
[<ffffffff82b98441>] port_event drivers/usb/core/hub.c:5509 [inline]
[<ffffffff82b98441>] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591
[<ffffffff81259229>] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275
[<ffffffff81259b19>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421
[<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292
[<ffffffff8100227f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
CVE-2021-47173
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix sysfs leak in alloc_iommu()
iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent
errors.
CVE-2021-47177
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return()
Commit de144ff4234f changes _pnfs_return_layout() to call
pnfs_mark_matching_lsegs_return() passing NULL as the struct
pnfs_layout_range argument. Unfortunately,
pnfs_mark_matching_lsegs_return() doesn't check if we have a value here
before dereferencing it, causing an oops.
I'm able to hit this crash consistently when running connectathon basic
tests on NFS v4.1/v4.2 against Ontap.
CVE-2021-47179
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: fix memory leak in nci_allocate_device
nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev.
Fix this by freeing hci_dev in nci_free_device.
BUG: memory leak
unreferenced object 0xffff888111ea6800 (size 1024):
comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff .........`......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline]
[<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline]
[<000000004bc25d43>] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784
[<00000000c59cff92>] nci_allocate_device net/nfc/nci/core.c:1170 [inline]
[<00000000c59cff92>] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132
[<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153
[<000000004da1b57e>] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345
[<00000000d506aed9>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554
[<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740
[<000000000ce658ca>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846
[<000000007067d05f>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
[<00000000f8e13372>] __device_attach+0x122/0x250 drivers/base/dd.c:914
[<000000009cf68860>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
[<00000000359c965a>] device_add+0x5be/0xc30 drivers/base/core.c:3109
[<00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164
[<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
[<00000000d40d36f6>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
[<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554
CVE-2021-47180
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: musb: tusb6010: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVE-2021-47181
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
occupying bytes 7 and 8 of the CDB. With this command, access to mode
pages larger than 255 bytes is thus possible. However, the CDB
allocation length field is set by assigning len to byte 8 only, thus
truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with
sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length
is increased to 8 and 4 respectively, and the buffer is zero filled
with these increased values, thus corrupting the memory following the
buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev->use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
* Use get_unaligned_be16() to retrieve the mode data length and block
descriptor length fields of the mode sense reply header instead of using
an open coded calculation.
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
Block Descriptor, which is the opposite of what the dbd argument
description was.
CVE-2021-47182
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix link down processing to address NULL pointer dereference
If an FC link down transition while PLOGIs are outstanding to fabric well
known addresses, outstanding ABTS requests may result in a NULL pointer
dereference. Driver unload requests may hang with repeated "2878" log
messages.
The Link down processing results in ABTS requests for outstanding ELS
requests. The Abort WQEs are sent for the ELSs before the driver had set
the link state to down. Thus the driver is sending the Abort with the
expectation that an ABTS will be sent on the wire. The Abort request is
stalled waiting for the link to come up. In some conditions the driver may
auto-complete the ELSs thus if the link does come up, the Abort completions
may reference an invalid structure.
Fix by ensuring that Abort set the flag to avoid link traffic if issued due
to conditions where the link failed.
CVE-2021-47183
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix NULL ptr dereference on VSI filter sync
Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that's causing a kernel oops.
CVE-2021-47184
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,
which look like this one:
Workqueue: events_unbound flush_to_ldisc
Call trace:
dump_backtrace+0x0/0x1ec
show_stack+0x24/0x30
dump_stack+0xd0/0x128
panic+0x15c/0x374
watchdog_timer_fn+0x2b8/0x304
__run_hrtimer+0x88/0x2c0
__hrtimer_run_queues+0xa4/0x120
hrtimer_interrupt+0xfc/0x270
arch_timer_handler_phys+0x40/0x50
handle_percpu_devid_irq+0x94/0x220
__handle_domain_irq+0x88/0xf0
gic_handle_irq+0x84/0xfc
el1_irq+0xc8/0x180
slip_unesc+0x80/0x214 [slip]
tty_ldisc_receive_buf+0x64/0x80
tty_port_default_receive_buf+0x50/0x90
flush_to_ldisc+0xbc/0x110
process_one_work+0x1d4/0x4b0
worker_thread+0x180/0x430
kthread+0x11c/0x120
In the testcase pty04, The first process call the write syscall to send
data to the pty master. At the same time, the workqueue will do the
flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends
data fastly in full time which will result in workqueue doing work in loop
for a long time and occuring softlockup in flush_to_ldisc with kernel
configured without preempt. So I add need_resched check and cond_resched
in the flush_to_ldisc loop to avoid it.
CVE-2021-47185
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Improve SCSI abort handling
The following has been observed on a test setup:
WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c
Call trace:
ufshcd_queuecommand+0x468/0x65c
scsi_send_eh_cmnd+0x224/0x6a0
scsi_eh_test_devices+0x248/0x418
scsi_eh_ready_devs+0xc34/0xe58
scsi_error_handler+0x204/0x80c
kthread+0x150/0x1b4
ret_from_fork+0x10/0x30
That warning is triggered by the following statement:
WARN_ON(lrbp->cmd);
Fix this warning by clearing lrbp->cmd from the abort handler.
CVE-2021-47188
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix memory ordering between normal and ordered work functions
Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.
This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:
pc : submit_compressed_extents+0x38/0x3d0
lr : async_cow_submit+0x50/0xd0
sp : ffff800015d4bc20
<registers omitted for brevity>
Call trace:
submit_compressed_extents+0x38/0x3d0
async_cow_submit+0x50/0xd0
run_ordered_work+0xc8/0x280
btrfs_work_helper+0x98/0x250
process_one_work+0x1f0/0x4ac
worker_thread+0x188/0x504
kthread+0x110/0x114
ret_from_fork+0x10/0x18
Fix this by adding respective barrier calls which ensure that all
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
setting the flag. At the same time add a read barrier after reading of
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
would be strictly ordered after reading the bit. This in turn ensures
are all accesses before WORK_DONE_BIT are going to be strictly ordered
before any access that can occur in ordered_func.
CVE-2021-47189
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()
The following warning was observed running syzkaller:
[ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;
[ 3813.830724] program syz-executor not setting count and/or reply_len properly
[ 3813.836956] ==================================================================
[ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0
[ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549
[ 3813.846612] Call Trace:
[ 3813.846995] dump_stack+0x108/0x15f
[ 3813.847524] print_address_description+0xa5/0x372
[ 3813.848243] kasan_report.cold+0x236/0x2a8
[ 3813.849439] check_memory_region+0x240/0x270
[ 3813.850094] memcpy+0x30/0x80
[ 3813.850553] sg_copy_buffer+0x157/0x1e0
[ 3813.853032] sg_copy_from_buffer+0x13/0x20
[ 3813.853660] fill_from_dev_buffer+0x135/0x370
[ 3813.854329] resp_readcap16+0x1ac/0x280
[ 3813.856917] schedule_resp+0x41f/0x1630
[ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0
[ 3813.862699] scsi_dispatch_cmd+0x330/0x950
[ 3813.863329] scsi_request_fn+0xd8e/0x1710
[ 3813.863946] __blk_run_queue+0x10b/0x230
[ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400
[ 3813.865220] sg_common_write.isra.0+0xe61/0x2420
[ 3813.871637] sg_write+0x6c8/0xef0
[ 3813.878853] __vfs_write+0xe4/0x800
[ 3813.883487] vfs_write+0x17b/0x530
[ 3813.884008] ksys_write+0x103/0x270
[ 3813.886268] __x64_sys_write+0x77/0xc0
[ 3813.886841] do_syscall_64+0x106/0x360
[ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9
This issue can be reproduced with the following syzkaller log:
r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0)
r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00')
open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)
r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782)
write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)
In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass
the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This
leads to OOB in sg_copy_buffer().
To solve this issue, define alloc_len as u32.
CVE-2021-47191
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cfg80211: call cfg80211_stop_ap when switch from P2P_GO type
If the userspace tools switch from NL80211_IFTYPE_P2P_GO to
NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it
does not call the cleanup cfg80211_stop_ap(), this leads to the
initialization of in-use data. For example, this path re-init the
sdata->assigned_chanctx_list while it is still an element of
assigned_vifs list, and makes that linked list corrupt.
CVE-2021-47194
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine
An error is detected with the following report when unloading the driver:
"KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"
The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the
flag is not cleared upon completion of the login.
This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set
to LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used
as an rpi_ids array index.
Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
lpfc_mbx_cmpl_fc_reg_login().
CVE-2021-47198
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iavf: free q_vectors before queues in iavf_disable_vf
iavf_free_queues() clears adapter->num_active_queues, which
iavf_free_q_vectors() relies on, so swap the order of these two function
calls in iavf_disable_vf(). This resolves a panic encountered when the
interface is disabled and then later brought up again after PF
communication is restored.
CVE-2021-47201
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
thermal: Fix NULL pointer dereferences in of_thermal_ functions
of_parse_thermal_zones() parses the thermal-zones node and registers a
thermal_zone device for each subnode. However, if a thermal zone is
consuming a thermal sensor and that thermal sensor device hasn't probed
yet, an attempt to set trip_point_*_temp for that thermal zone device
can cause a NULL pointer dereference. Fix it.
console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp
...
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
...
Call trace:
of_thermal_set_trip_temp+0x40/0xc4
trip_point_temp_store+0xc0/0x1dc
dev_attr_store+0x38/0x88
sysfs_kf_write+0x64/0xc0
kernfs_fop_write_iter+0x108/0x1d0
vfs_write+0x2f4/0x368
ksys_write+0x7c/0xec
__arm64_sys_write+0x20/0x30
el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc
do_el0_svc+0x28/0xa0
el0_svc+0x14/0x24
el0_sync_handler+0x88/0xec
el0_sync+0x1c0/0x200
While at it, fix the possible NULL pointer dereference in other
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
of_thermal_get_trend().
CVE-2021-47202
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass
the requests to the adapter. If such an attempt fails, a local "fail_msg"
string is set and a log message output. The job is then added to a
completions list for cancellation.
Processing of any further jobs from the txq list continues, but since
"fail_msg" remains set, jobs are added to the completions list regardless
of whether a wqe was passed to the adapter. If successfully added to
txcmplq, jobs are added to both lists resulting in list corruption.
Fix by clearing the fail_msg string after adding a job to the completions
list. This stops the subsequent jobs from being added to the completions
list unless they had an appropriate failure.
CVE-2021-47203
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove
Access to netdev after free_netdev() will cause use-after-free bug.
Move debug log before free_netdev() call to avoid it.
CVE-2021-47204
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: Unregister clocks/resets when unbinding
Currently, unbinding a CCU driver unmaps the device's MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.
This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.
Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.
CVE-2021-47205
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: host: ohci-tmio: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVE-2021-47206
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: gus: fix null pointer dereference on pointer block
The pointer block return from snd_gf1_dma_next_block could be
null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.
CVE-2021-47207
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.
CVE-2021-47211
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Update error handler for UCTX and UMEM
In the fast unload flow, the device state is set to internal error,
which indicates that the driver started the destroy process.
In this case, when a destroy command is being executed, it should return
MLX5_CMD_STAT_OK.
Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK
instead of EIO.
This fixes a call trace in the umem release process -
[ 2633.536695] Call Trace:
[ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]
[ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core]
[ 2633.539641] disable_device+0x8c/0x130 [ib_core]
[ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core]
[ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core]
[ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib]
[ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary]
[ 2633.544661] device_release_driver_internal+0x103/0x1f0
[ 2633.545679] bus_remove_device+0xf7/0x170
[ 2633.546640] device_del+0x181/0x410
[ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]
[ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core]
[ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core]
[ 2633.550864] remove_one+0x69/0xe0 [mlx5_core]
[ 2633.551819] pci_device_remove+0x3b/0xc0
[ 2633.552731] device_release_driver_internal+0x103/0x1f0
[ 2633.553746] unbind_store+0xf6/0x130
[ 2633.554657] kernfs_fop_write+0x116/0x190
[ 2633.555567] vfs_write+0xa5/0x1a0
[ 2633.556407] ksys_write+0x4f/0xb0
[ 2633.557233] do_syscall_64+0x5b/0x1a0
[ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 2633.559018] RIP: 0033:0x7f9977132648
[ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648
[ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001
[ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740
[ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0
[ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c
[ 2633.568725] ---[ end trace 10b4fe52945e544d ]---
CVE-2021-47212
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: advansys: Fix kernel pointer leak
Pointers should be printed with %p or %px rather than cast to 'unsigned
long' and printed with %lx.
Change %lx to %p to print the hashed pointer.
CVE-2021-47216
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails
Check for a valid hv_vp_index array prior to derefencing hv_vp_index when
setting Hyper-V's TSC change callback. If Hyper-V setup failed in
hyperv_init(), the kernel will still report that it's running under
Hyper-V, but will have silently disabled nearly all functionality.
BUG: kernel NULL pointer dereference, address: 0000000000000010
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:set_hv_tscchange_cb+0x15/0xa0
Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08
...
Call Trace:
kvm_arch_init+0x17c/0x280
kvm_init+0x31/0x330
vmx_init+0xba/0x13a
do_one_initcall+0x41/0x1c0
kernel_init_freeable+0x1f2/0x23b
kernel_init+0x16/0x120
ret_from_fork+0x22/0x30
CVE-2021-47217
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()
The following issue was observed running syzkaller:
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline]
BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815
CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe4/0x14a lib/dump_stack.c:118
print_address_description+0x73/0x280 mm/kasan/report.c:253
kasan_report_error mm/kasan/report.c:352 [inline]
kasan_report+0x272/0x370 mm/kasan/report.c:410
memcpy+0x1f/0x50 mm/kasan/kasan.c:302
memcpy include/linux/string.h:377 [inline]
sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021
resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772
schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429
scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835
scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896
scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034
__blk_run_queue_uncond block/blk-core.c:464 [inline]
__blk_run_queue+0x1a4/0x380 block/blk-core.c:484
blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78
sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847
sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716
sg_write+0x64/0xa0 drivers/scsi/sg.c:622
__vfs_write+0xed/0x690 fs/read_write.c:485
kill_bdev:block_device:00000000e138492c
vfs_write+0x184/0x4c0 fs/read_write.c:549
ksys_write+0x107/0x240 fs/read_write.c:599
do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
We get 'alen' from command its type is int. If userspace passes a large
length we will get a negative 'alen'.
Switch n, alen, and rlen to u32.
CVE-2021-47219
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2021-47220
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: aardvark: Fix kernel panic during PIO transfer
Trying to start a new PIO transfer by writing value 0 in PIO_START register
when previous transfer has not yet completed (which is indicated by value 1
in PIO_START) causes an External Abort on CPU, which results in kernel
panic:
SError Interrupt on CPU0, code 0xbf000002 -- SError
Kernel panic - not syncing: Asynchronous SError Interrupt
To prevent kernel panic, it is required to reject a new PIO transfer when
previous one has not finished yet.
If previous PIO transfer is not finished yet, the kernel may issue a new
PIO request only if the previous PIO transfer timed out.
In the past the root cause of this issue was incorrectly identified (as it
often happens during link retraining or after link down event) and special
hack was implemented in Trusted Firmware to catch all SError events in EL3,
to ignore errors with code 0xbf000002 and not forwarding any other errors
to kernel and instead throw panic from EL3 Trusted Firmware handler.
Links to discussion and patches about this issue:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541
But the real cause was the fact that during link retraining or after link
down event the PIO transfer may take longer time, up to the 1.44s until it
times out. This increased probability that a new PIO transfer would be
issued by kernel while previous one has not finished yet.
After applying this change into the kernel, it is possible to revert the
mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.
CVE-2021-47229
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: mcba_usb: fix memory leak in mcba_usb
Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS
Analyzer Tool. The problem was in unfreed usb_coherent.
In mcba_usb_start() 20 coherent buffers are allocated and there is
nothing, that frees them:
1) In callback function the urb is resubmitted and that's all
2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER
is not set (see mcba_usb_start) and this flag cannot be used with
coherent buffers.
Fail log:
| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected
| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)
So, all allocated buffers should be freed with usb_free_coherent()
explicitly
NOTE:
The same pattern for allocating and freeing coherent buffers
is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c
CVE-2021-47231
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: fix potential use-after-free in ec_bhf_remove
static void ec_bhf_remove(struct pci_dev *dev)
{
...
struct ec_bhf_priv *priv = netdev_priv(net_dev);
unregister_netdev(net_dev);
free_netdev(net_dev);
pci_iounmap(dev, priv->dma_io);
pci_iounmap(dev, priv->io);
...
}
priv is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing priv
pointer. So, fix it by moving free_netdev() after pci_iounmap()
calls.
CVE-2021-47235
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: cdc_eem: fix tx fixup skb leak
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
if skb_copy_expand() failed, it return NULL,
usbnet_start_xmit() will have no chance to free original skb.
fix it by free orginal skb in eem_tx_fixup() first,
then check skb clone status, if failed, return NULL to usbnet.
CVE-2021-47236
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: hamradio: fix memory leak in mkiss_close
My local syzbot instance hit memory leak in
mkiss_open()[1]. The problem was in missing
free_netdev() in mkiss_close().
In mkiss_open() netdevice is allocated and then
registered, but in mkiss_close() netdevice was
only unregistered, but not freed.
Fail log:
BUG: memory leak
unreferenced object 0xffff8880281ba000 (size 4096):
comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
hex dump (first 32 bytes):
61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0.............
00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............
backtrace:
[<ffffffff81a27201>] kvmalloc_node+0x61/0xf0
[<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80
[<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
[<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
[<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
[<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
[<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
[<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
[<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak
unreferenced object 0xffff8880141a9a00 (size 96):
comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
hex dump (first 32 bytes):
e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(....
98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@..........
backtrace:
[<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310
[<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0
[<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0
[<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80
[<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
[<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
[<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
[<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
[<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
[<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
[<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak
unreferenced object 0xffff8880219bfc00 (size 512):
comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
hex dump (first 32 bytes):
00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............
80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81a27201>] kvmalloc_node+0x61/0xf0
[<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80
[<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
[<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
[<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
[<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
[<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
[<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
[<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak
unreferenced object 0xffff888029b2b200 (size 256):
comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81a27201>] kvmalloc_node+0x61/0xf0
[<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80
[<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]
[<ffffffff842355db>] tty_ldisc_open+0x9b/0x110
[<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670
[<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440
[<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200
[<ffffffff8911263a>] do_syscall_64+0x3a/0xb0
[<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-47237
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: fix memory leak in ip_mc_add1_src
BUG: memory leak
unreferenced object 0xffff888101bc4c00 (size 32):
comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................
backtrace:
[<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline]
[<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline]
[<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline]
[<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095
[<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416
[<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline]
[<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423
[<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857
[<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117
[<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline]
[<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline]
[<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125
[<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47
[<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xae
In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set
link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,
because it was also called in igmpv3_clear_delrec().
Rough callgraph:
inetdev_destroy
-> ip_mc_destroy_dev
-> igmpv3_clear_delrec
-> ip_mc_clear_src
-> RCU_INIT_POINTER(dev->ip_ptr, NULL)
However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't
release in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the
NULL to dev->ip_ptr. As a result, in_dev cannot be obtained through
inetdev_by_index() and then in_dev->mc_list->sources cannot be released
by ip_mc_del1_src() in the sock_close. Rough call sequence goes like:
sock_close
-> __sock_release
-> inet_release
-> ip_mc_drop_socket
-> inetdev_by_index
-> ip_mc_leave_src
-> ip_mc_del_src
-> ip_mc_del1_src
So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free
in_dev->mc_list->sources.
CVE-2021-47238
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: Fix out of bounds when parsing TCP options
The TCP option parser in synproxy (synproxy_parse_options) could read
one byte out of bounds. When the length is 1, the execution flow gets
into the loop, reads one byte of the opcode, and if the opcode is
neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds
the length of 1.
This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack
out of bounds when parsing TCP options.").
v2 changes:
Added an early return when length < 0 to avoid calling
skb_header_pointer with negative length.
CVE-2021-47245
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix page reclaim for dead peer hairpin
When adding a hairpin flow, a firmware-side send queue is created for
the peer net device, which claims some host memory pages for its
internal ring buffer. If the peer net device is removed/unbound before
the hairpin flow is deleted, then the send queue is not destroyed which
leads to a stack trace on pci device remove:
[ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource
[ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110
[ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0
[ 748.002171] ------------[ cut here ]------------
[ 748.001177] FW pages counter is 4 after reclaiming all pages
[ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core] [ +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core]
[ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1
[ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core]
[ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 <0f> 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9
[ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286
[ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000
[ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51
[ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8
[ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30
[ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000
[ 748.001429] FS: 00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000
[ 748.001695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0
[ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 748.001654] Call Trace:
[ 748.000576] ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core]
[ 748.001416] ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core]
[ 748.001354] ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core]
[ 748.001203] mlx5_function_teardown+0x30/0x60 [mlx5_core]
[ 748.001275] mlx5_uninit_one+0xa7/0xc0 [mlx5_core]
[ 748.001200] remove_one+0x5f/0xc0 [mlx5_core]
[ 748.001075] pci_device_remove+0x9f/0x1d0
[ 748.000833] device_release_driver_internal+0x1e0/0x490
[ 748.001207] unbind_store+0x19f/0x200
[ 748.000942] ? sysfs_file_ops+0x170/0x170
[ 748.001000] kernfs_fop_write_iter+0x2bc/0x450
[ 748.000970] new_sync_write+0x373/0x610
[ 748.001124] ? new_sync_read+0x600/0x600
[ 748.001057] ? lock_acquire+0x4d6/0x700
[ 748.000908] ? lockdep_hardirqs_on_prepare+0x400/0x400
[ 748.001126] ? fd_install+0x1c9/0x4d0
[ 748.000951] vfs_write+0x4d0/0x800
[ 748.000804] ksys_write+0xf9/0x1d0
[ 748.000868] ? __x64_sys_read+0xb0/0xb0
[ 748.000811] ? filp_open+0x50/0x50
[ 748.000919] ? syscall_enter_from_user_mode+0x1d/0x50
[ 748.001223] do_syscall_64+0x3f/0x80
[ 748.000892] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 748.00
---truncated---
CVE-2021-47246
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
udp: fix race between close() and udp_abort()
Kaustubh reported and diagnosed a panic in udp_lib_lookup().
The root cause is udp_abort() racing with close(). Both
racing functions acquire the socket lock, but udp{v6}_destroy_sock()
release it before performing destructive actions.
We can't easily extend the socket lock scope to avoid the race,
instead use the SOCK_DEAD flag to prevent udp_abort from doing
any action when the critical race happens.
Diagnosed-and-tested-by: Kaustubh Pandey <kapandey@codeaurora.org>
CVE-2021-47248
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: rds: fix memory leak in rds_recvmsg
Syzbot reported memory leak in rds. The problem
was in unputted refcount in case of error.
int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
int msg_flags)
{
...
if (!rds_next_incoming(rs, &inc)) {
...
}
After this "if" inc refcount incremented and
if (rds_cmsg_recv(inc, msg, rs)) {
ret = -EFAULT;
goto out;
}
...
out:
return ret;
}
in case of rds_cmsg_recv() fail the refcount won't be
decremented. And it's easy to see from ftrace log, that
rds_inc_addref() don't have rds_inc_put() pair in
rds_recvmsg() after rds_cmsg_recv()
1) | rds_recvmsg() {
1) 3.721 us | rds_inc_addref();
1) 3.853 us | rds_message_inc_copy_to_user();
1) + 10.395 us | rds_cmsg_recv();
1) + 34.260 us | }
CVE-2021-47249
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: fix memory leak in netlbl_cipsov4_add_std
Reported by syzkaller:
BUG: memory leak
unreferenced object 0xffff888105df7000 (size 64):
comm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000e67ed558>] kmalloc include/linux/slab.h:590 [inline]
[<00000000e67ed558>] kzalloc include/linux/slab.h:720 [inline]
[<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]
[<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416
[<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739
[<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
[<00000000204d7a1c>] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800
[<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504
[<00000000d78b9d2c>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811
[<000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
[<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340
[<00000000d5fd43b8>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929
[<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [inline]
[<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674
[<00000000321d1969>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350
[<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404
[<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433
[<000000004ee8b6a5>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47
[<00000000171c7cee>] entry_SYSCALL_64_after_hwframe+0x44/0xae
The memory of doi_def->map.std pointing is allocated in
netlbl_cipsov4_add_std, but no place has freed it. It should be
freed in cipso_v4_doi_free which frees the cipso DOI resource.
CVE-2021-47250
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid WARN_ON timing related checks
The soft/batadv interface for a queued OGM can be changed during the time
the OGM was queued for transmission and when the OGM is actually
transmitted by the worker.
But WARN_ON must be used to denote kernel bugs and not to print simple
warnings. A warning can simply be printed using pr_warn.
CVE-2021-47252
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix use-after-free in gfs2_glock_shrink_scan
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
remove the glock from the lru list in __gfs2_glock_put().
On the shrink scan path, the same flag is cleared under lru_lock but because
of cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the
put side can be made without deleting the glock from the lru list.
Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to
ensure correct behavior on both sides - clear GLF_LRU after list_del under
lru_lock.
CVE-2021-47254
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: fix null deref in parse dev addr
Fix a logic error that could result in a null deref if the user sets
the mode incorrectly for the given addr type.
CVE-2021-47257
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix error handling of scsi_host_alloc()
After device is initialized via device_initialize(), or its name is set via
dev_set_name(), the device has to be freed via put_device(). Otherwise
device name will be leaked because it is allocated dynamically in
dev_set_name().
Fix the leak by replacing kfree() with put_device(). Since
scsi_host_dev_release() properly handles IDA and kthread removal, remove
special-casing these from the error handling as well.
CVE-2021-47258
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a potential NULL dereference in nfs_get_client()
None of the callers are expecting NULL returns from nfs_get_client() so
this code will lead to an Oops. It's better to return an error
pointer. I expect that this is dead code so hopefully no one is
affected.
CVE-2021-47260
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix initializing CQ fragments buffer
The function init_cq_frag_buf() can be called to initialize the current CQ
fragments buffer cq->buf, or the temporary cq->resize_buf that is filled
during CQ resize operation.
However, the offending commit started to use function get_cqe() for
getting the CQEs, the issue with this change is that get_cqe() always
returns CQEs from cq->buf, which leads us to initialize the wrong buffer,
and in case of enlarging the CQ we try to access elements beyond the size
of the current cq->buf and eventually hit a kernel panic.
[exception RIP: init_cq_frag_buf+103]
[ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]
[ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]
[ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]
[ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]
[ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]
[ffff9f799ddcbec8] kthread at ffffffffa66c5da1
[ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd
Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that
takes the correct source buffer as a parameter.
CVE-2021-47261
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
RDMA: Verify port when creating flow rule
Validate port value provided by the user and with that remove no longer
needed validation by the driver. The missing check in the mlx5_ib driver
could cause to the below oops.
Call trace:
_create_flow_rule+0x2d4/0xf28 [mlx5_ib]
mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
do_vfs_ioctl+0xd0/0xaf0
ksys_ioctl+0x84/0xb4
__arm64_sys_ioctl+0x28/0xc4
el0_svc_common.constprop.3+0xa4/0x254
el0_svc_handler+0x84/0xa0
el0_svc+0x10/0x26c
Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)
CVE-2021-47265
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: fix various gadget panics on 10gbps cabling
usb_assign_descriptors() is called with 5 parameters,
the last 4 of which are the usb_descriptor_header for:
full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),
high-speed (USB2.0 - 480Mbps),
super-speed (USB3.0 - 5Gbps),
super-speed-plus (USB3.1 - 10Gbps).
The differences between full/high/super-speed descriptors are usually
substantial (due to changes in the maximum usb block size from 64 to 512
to 1024 bytes and other differences in the specs), while the difference
between 5 and 10Gbps descriptors may be as little as nothing
(in many cases the same tuning is simply good enough).
However if a gadget driver calls usb_assign_descriptors() with
a NULL descriptor for super-speed-plus and is then used on a max 10gbps
configuration, the kernel will crash with a null pointer dereference,
when a 10gbps capable device port + cable + host port combination shows up.
(This wouldn't happen if the gadget max-speed was set to 5gbps, but
it of course defaults to the maximum, and there's no real reason to
artificially limit it)
The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,
if a 10gbps descriptor wasn't provided.
Obviously this won't fix the problem if the 5gbps descriptor is also
NULL, but such cases can't be so trivially solved (and any such gadgets
are unlikely to be used with USB3 ports any way).
CVE-2021-47267
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: ep0: fix NULL pointer exception
There is no validation of the index from dwc3_wIndex_to_dep() and we might
be referring a non-existing ep and trigger a NULL pointer exception. In
certain configurations we might use fewer eps and the index might wrongly
indicate a larger ep index than existing.
By adding this validation from the patch we can actually report a wrong
index back to the caller.
In our usecase we are using a composite device on an older kernel, but
upstream might use this fix also. Unfortunately, I cannot describe the
hardware for others to reproduce the issue as it is a proprietary
implementation.
[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4
[ 82.966891] Mem abort info:
[ 82.969663] ESR = 0x96000006
[ 82.972703] Exception class = DABT (current EL), IL = 32 bits
[ 82.978603] SET = 0, FnV = 0
[ 82.981642] EA = 0, S1PTW = 0
[ 82.984765] Data abort info:
[ 82.987631] ISV = 0, ISS = 0x00000006
[ 82.991449] CM = 0, WnR = 0
[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc
[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000
[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)
[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1
[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)
[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c
[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94
...
[ 83.141788] Call trace:
[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c
[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94
[ 83.181546] ---[ end trace aac6b5267d84c32f ]---
CVE-2021-47269
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: fix various gadgets null ptr deref on 10gbps cabling.
This avoids a null pointer dereference in
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
by simply reusing the 5gbps config for 10gbps.
CVE-2021-47270
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Correct the length check which causes memory corruption
We've suffered from severe kernel crashes due to memory corruption on
our production environment, like,
Call Trace:
[1640542.554277] general protection fault: 0000 [#1] SMP PTI
[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G
[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190
[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286
[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:
0000000006e931bf
[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:
ffff9a45ff004300
[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:
0000000000000000
[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
ffffffff9a20608d
[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:
696c662f65636976
[1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)
knlGS:0000000000000000
[1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:
00000000003606e0
[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[1640542.566742] Call Trace:
[1640542.567009] anon_vma_clone+0x5d/0x170
[1640542.567417] __split_vma+0x91/0x1a0
[1640542.567777] do_munmap+0x2c6/0x320
[1640542.568128] vm_munmap+0x54/0x70
[1640542.569990] __x64_sys_munmap+0x22/0x30
[1640542.572005] do_syscall_64+0x5b/0x1b0
[1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[1640542.575642] RIP: 0033:0x7f45d6e61e27
James Wang has reproduced it stably on the latest 4.19 LTS.
After some debugging, we finally proved that it's due to ftrace
buffer out-of-bound access using a debug tool as follows:
[ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
[ 86.780806] no_context+0xdf/0x3c0
[ 86.784327] __do_page_fault+0x252/0x470
[ 86.788367] do_page_fault+0x32/0x140
[ 86.792145] page_fault+0x1e/0x30
[ 86.795576] strncpy_from_unsafe+0x66/0xb0
[ 86.799789] fetch_memory_string+0x25/0x40
[ 86.804002] fetch_deref_string+0x51/0x60
[ 86.808134] kprobe_trace_func+0x32d/0x3a0
[ 86.812347] kprobe_dispatcher+0x45/0x50
[ 86.816385] kprobe_ftrace_handler+0x90/0xf0
[ 86.820779] ftrace_ops_assist_func+0xa1/0x140
[ 86.825340] 0xffffffffc00750bf
[ 86.828603] do_sys_open+0x5/0x1f0
[ 86.832124] do_syscall_64+0x5b/0x1b0
[ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9
commit b220c049d519 ("tracing: Check length before giving out
the filter buffer") adds length check to protect trace data
overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent
overflow entirely, the length check should also take the sizeof
entry->array[0] into account, since this array[0] is filled the
length of trace data and occupy addtional space and risk overflow.
CVE-2021-47274
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bcache: avoid oversized read request in cache missing code path
In the cache missing code path of cached device, if a proper location
from the internal B+ tree is matched for a cache miss range, function
cached_dev_cache_miss() will be called in cache_lookup_fn() in the
following code block,
[code block 1]
526 unsigned int sectors = KEY_INODE(k) == s->iop.inode
527 ? min_t(uint64_t, INT_MAX,
528 KEY_START(k) - bio->bi_iter.bi_sector)
529 : INT_MAX;
530 int ret = s->d->cache_miss(b, s, bio, sectors);
Here s->d->cache_miss() is the call backfunction pointer initialized as
cached_dev_cache_miss(), the last parameter 'sectors' is an important
hint to calculate the size of read request to backing device of the
missing cache data.
Current calculation in above code block may generate oversized value of
'sectors', which consequently may trigger 2 different potential kernel
panics by BUG() or BUG_ON() as listed below,
1) BUG_ON() inside bch_btree_insert_key(),
[code block 2]
886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k));
2) BUG() inside biovec_slab(),
[code block 3]
51 default:
52 BUG();
53 return NULL;
All the above panics are original from cached_dev_cache_miss() by the
oversized parameter 'sectors'.
Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate
the size of data read from backing device for the cache missing. This
size is stored in s->insert_bio_sectors by the following lines of code,
[code block 4]
909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);
Then the actual key inserting to the internal B+ tree is generated and
stored in s->iop.replace_key by the following lines of code,
[code block 5]
911 s->iop.replace_key = KEY(s->iop.inode,
912 bio->bi_iter.bi_sector + s->insert_bio_sectors,
913 s->insert_bio_sectors);
The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from
the above code block.
And the bio sending to backing device for the missing data is allocated
with hint from s->insert_bio_sectors by the following lines of code,
[code block 6]
926 cache_bio = bio_alloc_bioset(GFP_NOWAIT,
927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS),
928 &dc->disk.bio_split);
The oversized parameter 'sectors' may trigger panic 2) by BUG() from the
agove code block.
Now let me explain how the panics happen with the oversized 'sectors'.
In code block 5, replace_key is generated by macro KEY(). From the
definition of macro KEY(),
[code block 7]
71 #define KEY(inode, offset, size) \
72 ((struct bkey) { \
73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \
74 .low = (offset) \
75 })
Here 'size' is 16bits width embedded in 64bits member 'high' of struct
bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is
very probably to be larger than (1<<16) - 1, which makes the bkey size
calculation in code block 5 is overflowed. In one bug report the value
of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors'
results the overflowed s->insert_bio_sectors in code block 4, then makes
size field of s->iop.replace_key to be 0 in code block 5. Then the 0-
sized s->iop.replace_key is inserted into the internal B+ tree as cache
missing check key (a special key to detect and avoid a racing between
normal write request and cache missing read request) as,
[code block 8]
915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key);
Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey
size check BUG_ON() in code block 2, and causes the kernel panic 1).
Another ke
---truncated---
CVE-2021-47275
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Do not blindly read the ip address in ftrace_bug()
It was reported that a bug on arm64 caused a bad ip address to be used for
updating into a nop in ftrace_init(), but the error path (rightfully)
returned -EINVAL and not -EFAULT, as the bug caused more than one error to
occur. But because -EINVAL was returned, the ftrace_bug() tried to report
what was at the location of the ip address, and read it directly. This
caused the machine to panic, as the ip was not pointing to a valid memory
address.
Instead, read the ip address with copy_from_kernel_nofault() to safely
access the memory, and if it faults, report that the address faulted,
otherwise report what was in that location.
CVE-2021-47276
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kvm: avoid speculation-based attacks from out-of-range memslot accesses
KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot. The translation is
performed in __gfn_to_hva_memslot using the following formula:
hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
It is expected that gfn falls within the boundaries of the guest's
physical memory. However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.
__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva. If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.
Right now it's not clear if there are any cases in which this is
exploitable. One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86. Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier. However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space. Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets. Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached. This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses.
CVE-2021-47277
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm: Fix use-after-free read in drm_getunique()
There is a time-of-check-to-time-of-use error in drm_getunique() due
to retrieving file_priv->master prior to locking the device's master
mutex.
An example can be seen in the crash report of the use-after-free error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803
In the report, the master pointer was used after being freed. This is
because another process had acquired the device's master mutex in
drm_setmaster_ioctl(), then overwrote fpriv->master in
drm_new_set_master(). The old value of fpriv->master was subsequently
freed before the mutex was unlocked.
To fix this, we lock the device's master mutex before retrieving the
pointer from from fpriv->master. This patch passes the Syzbot
reproducer test.
CVE-2021-47280
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix race of snd_seq_timer_open()
The timer instance per queue is exclusive, and snd_seq_timer_open()
should have managed the concurrent accesses. It looks as if it's
checking the already existing timer instance at the beginning, but
it's not right, because there is no protection, hence any later
concurrent call of snd_seq_timer_open() may override the timer
instance easily. This may result in UAF, as the leftover timer
instance can keep running while the queue itself gets closed, as
spotted by syzkaller recently.
For avoiding the race, add a proper check at the assignment of
tmr->timeri again, and return -EBUSY if it's been already registered.
CVE-2021-47281
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: netjet: Fix crash in nj_probe:
'nj_setup' in netjet.c might fail with -EIO and in this case
'card->irq' is initialized and is bigger than zero. A subsequent call to
'nj_release' will free the irq that has not been requested.
Fix this bug by deleting the previous assignment to 'card->irq' and just
keep the assignment before 'request_irq'.
The KASAN's log reveals it:
[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826
free_irq+0x100/0x480
[ 3.355112 ] Modules linked in:
[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.13.0-rc1-00144-g25a1298726e #13
[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480
[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18
4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5
ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80
[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082
[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:
0000000000000000
[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:
00000000ffffffff
[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:
0000000000000000
[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:
0000000000000000
[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:
ffff888104dc80a8
[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)
knlGS:0000000000000000
[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:
00000000000006f0
[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 3.362175 ] Call Trace:
[ 3.362175 ] nj_release+0x51/0x1e0
[ 3.362175 ] nj_probe+0x450/0x950
[ 3.362175 ] ? pci_device_remove+0x110/0x110
[ 3.362175 ] local_pci_probe+0x45/0xa0
[ 3.362175 ] pci_device_probe+0x12b/0x1d0
[ 3.362175 ] really_probe+0x2a9/0x610
[ 3.362175 ] driver_probe_device+0x90/0x1d0
[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20
[ 3.362175 ] device_driver_attach+0x68/0x70
[ 3.362175 ] __driver_attach+0x124/0x1b0
[ 3.362175 ] ? device_driver_attach+0x70/0x70
[ 3.362175 ] bus_for_each_dev+0xbb/0x110
[ 3.362175 ] ? rdinit_setup+0x45/0x45
[ 3.362175 ] driver_attach+0x27/0x30
[ 3.362175 ] bus_add_driver+0x1eb/0x2a0
[ 3.362175 ] driver_register+0xa9/0x180
[ 3.362175 ] __pci_register_driver+0x82/0x90
[ 3.362175 ] ? w6692_init+0x38/0x38
[ 3.362175 ] nj_init+0x36/0x38
[ 3.362175 ] do_one_initcall+0x7f/0x3d0
[ 3.362175 ] ? rdinit_setup+0x45/0x45
[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80
[ 3.362175 ] kernel_init_freeable+0x2aa/0x301
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
[ 3.362175 ] kernel_init+0x18/0x190
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
[ 3.362175 ] ret_from_fork+0x1f/0x30
[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...
[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.13.0-rc1-00144-g25a1298726e #13
[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 3.362175 ] Call Trace:
[ 3.362175 ] dump_stack+0xba/0xf5
[ 3.362175 ] ? free_irq+0x100/0x480
[ 3.362175 ] panic+0x15a/0x3f2
[ 3.362175 ] ? __warn+0xf2/0x150
[ 3.362175 ] ? free_irq+0x100/0x480
[ 3.362175 ] __warn+0x108/0x150
[ 3.362175 ] ? free_irq+0x100/0x480
[ 3.362175 ] report_bug+0x119/0x1c0
[ 3.362175 ] handle_bug+0x3b/0x80
[ 3.362175 ] exc_invalid_op+0x18/0x70
[ 3.362175 ] asm_exc_invalid_op+0x12/0x20
[ 3.362175 ] RIP: 0010:free_irq+0x100
---truncated---
CVE-2021-47284
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2021-47285
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
Fix an 11-year old bug in ngene_command_config_free_buf() while
addressing the following warnings caught with -Warray-bounds:
arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
The problem is that the original code is trying to copy 6 bytes of
data into a one-byte size member _config_ of the wrong structue
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
legitimate compiler warning because memcpy() overruns the length
of &com.cmd.ConfigureBuffers.config. It seems that the right
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
6 more members apart from the header _hdr_. Also, the name of
the function ngene_command_config_free_buf() suggests that the actual
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
(which takes place in the function ngene_command_config_buf(), above).
Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
the destination address, instead of &com.cmd.ConfigureBuffers.config,
when calling memcpy().
This also helps with the ongoing efforts to globally enable
-Warray-bounds and get us closer to being able to tighten the
FORTIFY_SOURCE routines on memcpy().
CVE-2021-47288
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_skbmod: Skip non-Ethernet packets
Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2
protocol, which is not always the case. As an example, for CAN devices:
$ ip link add dev vcan0 type vcan
$ ip link set up vcan0
$ tc qdisc add dev vcan0 root handle 1: htb
$ tc filter add dev vcan0 parent 1: protocol ip prio 10 \
matchall action skbmod swap mac
Doing the above silently corrupts all the packets. Do not perform skbmod
actions for non-Ethernet packets.
CVE-2021-47293
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netrom: Decrease sock refcount when sock timers expire
Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().
Function sk_reset_timer() will increase the refcount of sock if it is
called on an inactive timer, hence, in case the timer expires, we need to
decrease the refcount ourselves in the handler, otherwise, the sock
refcount will be unbalanced and the sock will never be freed.
CVE-2021-47294
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_partial_destroy_work
Syzbot reported memory leak in tcindex_set_parms(). The problem was in
non-freed perfect hash in tcindex_partial_destroy_work().
In tcindex_set_parms() new tcindex_data is allocated and some fields from
old one are copied to new one, but not the perfect hash. Since
tcindex_partial_destroy_work() is the destroy function for old
tcindex_data, we need to free perfect hash to avoid memory leak.
CVE-2021-47295
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fix uninit-value in caif_seqpkt_sendmsg
When nr_segs equal to zero in iovec_from_user, the object
msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg
which is defined in ___sys_sendmsg. So we cann't just judge
msg->msg_iter.iov->base directlly. We can use nr_segs to judge
msg in caif_seqpkt_sendmsg whether has data buffers.
=====================================================
BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg net/socket.c:672 [inline]
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343
___sys_sendmsg net/socket.c:2397 [inline]
__sys_sendmmsg+0x808/0xc90 net/socket.c:2480
__compat_sys_sendmmsg net/compat.c:656 [inline]
CVE-2021-47297
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igb: Fix use-after-free error during reset
Cleans the next descriptor to watch (next_to_watch) when cleaning the
TX ring.
Failure to do so can cause invalid memory accesses. If igb_poll() runs
while the controller is reset this can lead to the driver try to free
a skb that was already freed.
(The crash is harder to reproduce with the igb driver, but the same
potential problem exists as the code is identical to igc)
CVE-2021-47301
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igc: Fix use-after-free error during reset
Cleans the next descriptor to watch (next_to_watch) when cleaning the
TX ring.
Failure to do so can cause invalid memory accesses. If igc_poll() runs
while the controller is being reset this can lead to the driver try to
free a skb that was already freed.
Log message:
[ 101.525242] refcount_t: underflow; use-after-free.
[ 101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0
[ 101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)
x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)
ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)
rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)
soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)
iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)
soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)
autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)
i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)
[ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)
e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)
usbcore(E) drm(E) button(E) video(E)
[ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G E 5.10.30-rt37-tsn1-rt-ipipe #ipipe
[ 101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017
[ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0
[ 101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48
44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3
[ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286
[ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001
[ 101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff
[ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50
[ 101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00
[ 101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40
[ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000
[ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0
[ 101.525343] Call Trace:
[ 101.525346] sock_wfree+0x9c/0xa0
[ 101.525353] unix_destruct_scm+0x7b/0xa0
[ 101.525358] skb_release_head_state+0x40/0x90
[ 101.525362] skb_release_all+0xe/0x30
[ 101.525364] napi_consume_skb+0x57/0x160
[ 101.525367] igc_poll+0xb7/0xc80 [igc]
[ 101.525376] ? sched_clock+0x5/0x10
[ 101.525381] ? sched_clock_cpu+0xe/0x100
[ 101.525385] net_rx_action+0x14c/0x410
[ 101.525388] __do_softirq+0xe9/0x2f4
[ 101.525391] __local_bh_enable_ip+0xe3/0x110
[ 101.525395] ? irq_finalize_oneshot.part.47+0xe0/0xe0
[ 101.525398] irq_forced_thread_fn+0x6a/0x80
[ 101.525401] irq_thread+0xe8/0x180
[ 101.525403] ? wake_threads_waitq+0x30/0x30
[ 101.525406] ? irq_thread_check_affinity+0xd0/0xd0
[ 101.525408] kthread+0x183/0x1a0
[ 101.525412] ? kthread_park+0x80/0x80
[ 101.525415] ret_from_fork+0x22/0x30
CVE-2021-47302
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dma-buf/sync_file: Don't leak fences on merge failure
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure that i and fences are always
zero-initialized and dma_fence_put() all the fences and kfree(fences) on
every error path.
CVE-2021-47305
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent NULL deref in cifs_compose_mount_options()
The optional @ref parameter might contain an NULL node_name, so
prevent dereferencing it in cifs_compose_mount_options().
Addresses-Coverity: 1476408 ("Explicit null dereferenced")
CVE-2021-47307
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix array index out of bound exception
Fix array index out of bound exception in fc_rport_prli_resp().
CVE-2021-47308
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: validate lwtstate->data before returning from skb_tunnel_info()
skb_tunnel_info() returns pointer of lwtstate->data as ip_tunnel_info
type without validation. lwtstate->data can have various types such as
mpls_iptunnel_encap, etc and these are not compatible.
So skb_tunnel_info() should validate before returning that pointer.
Splat looks like:
BUG: KASAN: slab-out-of-bounds in vxlan_get_route+0x418/0x4b0 [vxlan]
Read of size 2 at addr ffff888106ec2698 by task ping/811
CPU: 1 PID: 811 Comm: ping Not tainted 5.13.0+ #1195
Call Trace:
dump_stack_lvl+0x56/0x7b
print_address_description.constprop.8.cold.13+0x13/0x2ee
? vxlan_get_route+0x418/0x4b0 [vxlan]
? vxlan_get_route+0x418/0x4b0 [vxlan]
kasan_report.cold.14+0x83/0xdf
? vxlan_get_route+0x418/0x4b0 [vxlan]
vxlan_get_route+0x418/0x4b0 [vxlan]
[ ... ]
vxlan_xmit_one+0x148b/0x32b0 [vxlan]
[ ... ]
vxlan_xmit+0x25c5/0x4780 [vxlan]
[ ... ]
dev_hard_start_xmit+0x1ae/0x6e0
__dev_queue_xmit+0x1f39/0x31a0
[ ... ]
neigh_xmit+0x2f9/0x940
mpls_xmit+0x911/0x1600 [mpls_iptunnel]
lwtunnel_xmit+0x18f/0x450
ip_finish_output2+0x867/0x2040
[ ... ]
CVE-2021-47309
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ti: fix UAF in tlan_remove_one
priv is netdev private data and it cannot be
used after free_netdev() call. Using priv after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.
CVE-2021-47310
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: qcom/emac: fix UAF in emac_remove
adpt is netdev private data and it cannot be
used after free_netdev() call. Using adpt after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.
CVE-2021-47311
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
memory: fsl_ifc: fix leak of private memory on probe failure
On probe error the driver should free the memory allocated for private
structure. Fix this by using resource-managed allocation.
CVE-2021-47314
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
memory: fsl_ifc: fix leak of IO mapping on probe failure
On probe error the driver should unmap the IO memory. Smatch reports:
drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.
CVE-2021-47315
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: Fix memory leak among suspend/resume procedure
The vblk->vqs should be freed before we call init_vqs()
in virtblk_restore().
CVE-2021-47319
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix acl memory leak of posix_acl_create()
When looking into another nfs xfstests report, I found acl and
default_acl in nfs3_proc_create() and nfs3_proc_mknod() error
paths are possibly leaked. Fix them in advance.
CVE-2021-47320
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
watchdog: Fix possible use-after-free by calling del_timer_sync()
This driver's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
CVE-2021-47321
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
CVE-2021-47323
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
watchdog: Fix possible use-after-free in wdt_startup()
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
CVE-2021-47324
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: 8250: serial_cs: Fix a memory leak in error handling path
In the probe function, if the final 'serial_config()' fails, 'info' is
leaking.
Add a resource handling path to free this memory.
CVE-2021-47330
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
misc/libmasm/module: Fix two use after free in ibmasm_init_one
In ibmasm_init_one, it calls ibmasm_init_remote_input_dev().
Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are
allocated by input_allocate_device(), and assigned to
sp->remote.mouse_dev and sp->remote.keybd_dev respectively.
In the err_free_devices error branch of ibmasm_init_one,
mouse_dev and keybd_dev are freed by input_free_device(), and return
error. Then the execution runs into error_send_message error branch
of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called
to unregister the freed sp->remote.mouse_dev and sp->remote.keybd_dev.
My patch add a "error_init_remote" label to handle the error of
ibmasm_init_remote_input_dev(), to avoid the uaf bugs.
CVE-2021-47334
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix bad pointer dereference when ehandler kthread is invalid
Commit 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")
changed the allocation logic to call put_device() to perform host cleanup
with the assumption that IDA removal and stopping the kthread would
properly be performed in scsi_host_dev_release(). However, in the unlikely
case that the error handler thread fails to spawn, shost->ehandler is set
to ERR_PTR(-ENOMEM).
The error handler cleanup code in scsi_host_dev_release() will call
kthread_stop() if shost->ehandler != NULL which will always be the case
whether the kthread was successfully spawned or not. In the case that it
failed to spawn this has the nasty side effect of trying to dereference an
invalid pointer when kthread_stop() is called. The following splat provides
an example of this behavior in the wild:
scsi host11: error handler thread failed to spawn, error = -4
Kernel attempted to read user page (10c) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x0000010c
Faulting instruction address: 0xc00000000818e9a8
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region
hash dm_log dm_mod fuse overlay squashfs loop
CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1
NIP: c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8
REGS: c000000037d12ea0 TRAP: 0300 Not tainted (5.13.0-rc7)
MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28228228
XER: 20040001
CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0
GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc
GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000
GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff
GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0
GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288
GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898
GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000
GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc
NIP [c00000000818e9a8] kthread_stop+0x38/0x230
LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160
Call Trace:
[c000000033bb2c48] 0xc000000033bb2c48 (unreliable)
[c0000000089846e8] scsi_host_dev_release+0x98/0x160
[c00000000891e960] device_release+0x60/0x100
[c0000000087e55c4] kobject_release+0x84/0x210
[c00000000891ec78] put_device+0x28/0x40
[c000000008984ea4] scsi_host_alloc+0x314/0x430
[c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi]
[c000000008110104] vio_bus_probe+0xa4/0x4b0
[c00000000892a860] really_probe+0x140/0x680
[c00000000892aefc] driver_probe_device+0x15c/0x200
[c00000000892b63c] device_driver_attach+0xcc/0xe0
[c00000000892b740] __driver_attach+0xf0/0x200
[c000000008926f28] bus_for_each_dev+0xa8/0x130
[c000000008929ce4] driver_attach+0x34/0x50
[c000000008928fc0] bus_add_driver+0x1b0/0x300
[c00000000892c798] driver_register+0x98/0x1a0
[c00000000810eb60] __vio_register_driver+0x80/0xe0
[c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi]
[c0000000080121d0] do_one_initcall+0x60/0x2d0
[c000000008261abc] do_init_module+0x7c/0x320
[c000000008265700] load_module+0x2350/0x25b0
[c000000008265cb4] __do_sys_finit_module+0xd4/0x160
[c000000008031110] system_call_exception+0x150/0x2d0
[c00000000800d35c] system_call_common+0xec/0x278
Fix this be nulling shost->ehandler when the kthread fails to spawn.
CVE-2021-47337
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: mmio: Fix use-after-free Read in kvm_vm_ioctl_unregister_coalesced_mmio
BUG: KASAN: use-after-free in kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183
Read of size 8 at addr ffff0000c03a2500 by task syz-executor083/4269
CPU: 5 PID: 4269 Comm: syz-executor083 Not tainted 5.10.0 #7
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x2d0 arch/arm64/kernel/stacktrace.c:132
show_stack+0x28/0x34 arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x110/0x164 lib/dump_stack.c:118
print_address_description+0x78/0x5c8 mm/kasan/report.c:385
__kasan_report mm/kasan/report.c:545 [inline]
kasan_report+0x148/0x1e4 mm/kasan/report.c:562
check_memory_region_inline mm/kasan/generic.c:183 [inline]
__asan_load8+0xb4/0xbc mm/kasan/generic.c:252
kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183
kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]
do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220
el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367
el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383
el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670
Allocated by task 4269:
stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc+0xdc/0x120 mm/kasan/common.c:461
kasan_kmalloc+0xc/0x14 mm/kasan/common.c:475
kmem_cache_alloc_trace include/linux/slab.h:450 [inline]
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:664 [inline]
kvm_vm_ioctl_register_coalesced_mmio+0x78/0x1cc arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:146
kvm_vm_ioctl+0x7e8/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3746
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]
do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220
el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367
el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383
el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670
Freed by task 4269:
stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track+0x38/0x6c mm/kasan/common.c:56
kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:355
__kasan_slab_free+0x124/0x150 mm/kasan/common.c:422
kasan_slab_free+0x10/0x1c mm/kasan/common.c:431
slab_free_hook mm/slub.c:1544 [inline]
slab_free_freelist_hook mm/slub.c:1577 [inline]
slab_free mm/slub.c:3142 [inline]
kfree+0x104/0x38c mm/slub.c:4124
coalesced_mmio_destructor+0x94/0xa4 arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:102
kvm_iodevice_destructor include/kvm/iodev.h:61 [inline]
kvm_io_bus_unregister_dev+0x248/0x280 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:4374
kvm_vm_ioctl_unregister_coalesced_mmio+0x158/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:186
kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall arch/arm64/kernel/sys
---truncated---
CVE-2021-47341
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm btree remove: assign new_root only when removal succeeds
remove_raw() in dm_btree_remove() may fail due to IO read error
(e.g. read the content of origin block fails during shadowing),
and the value of shadow_spine::root is uninitialized, but
the uninitialized value is still assign to new_root in the
end of dm_btree_remove().
For dm-thin, the value of pmd->details_root or pmd->root will become
an uninitialized value, so if trying to read details_info tree again
out-of-bound memory may occur as showed below:
general protection fault, probably for non-canonical address 0x3fdcb14c8d7520
CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6
Hardware name: QEMU Standard PC
RIP: 0010:metadata_ll_load_ie+0x14/0x30
Call Trace:
sm_metadata_count_is_more_than_one+0xb9/0xe0
dm_tm_shadow_block+0x52/0x1c0
shadow_step+0x59/0xf0
remove_raw+0xb2/0x170
dm_btree_remove+0xf4/0x1c0
dm_pool_delete_thin_device+0xc3/0x140
pool_message+0x218/0x2b0
target_message+0x251/0x290
ctl_ioctl+0x1c4/0x4d0
dm_ctl_ioctl+0xe/0x20
__x64_sys_ioctl+0x7b/0xb0
do_syscall_64+0x40/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixing it by only assign new_root when removal succeeds
CVE-2021-47343
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: zr364xx: fix memory leak in zr364xx_start_readpipe
syzbot reported memory leak in zr364xx driver.
The problem was in non-freed urb in case of
usb_submit_urb() fail.
backtrace:
[<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline]
[<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74
[<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022
[<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]
[<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516
[<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576
CVE-2021-47344
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix rdma_resolve_route() memory leak
Fix a memory leak when "mda_resolve_route() is called more than once on
the same "rdma_cm_id".
This is possible if cma_query_handler() triggers the
RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and
allows rdma_resolve_route() to be called again.
CVE-2021-47345
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wl1251: Fix possible buffer overflow in wl1251_cmd_scan
Function wl1251_cmd_scan calls memcpy without checking the length.
Harden by checking the length is within the maximum allowed size.
CVE-2021-47347
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: Add validation for used length
This adds validation for used length (might come
from an untrusted device) to avoid data corruption
or loss.
CVE-2021-47352
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix NULL pointer dereference in udf_symlink function
In function udf_symlink, epos.bh is assigned with the value returned
by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c
and returns the value of sb_getblk function that could be NULL.
Then, epos.bh is used without any check, causing a possible
NULL pointer dereference when sb_getblk fails.
This fix adds a check to validate the value of epos.bh.
CVE-2021-47353
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Avoid data corruptions
Wait for all dependencies of a job to complete before
killing it to avoid data corruptions.
CVE-2021-47354
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
CVE-2021-47355
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible use-after-free in HFC_cleanup()
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
CVE-2021-47356
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: iphase: fix possible use-after-free in ia_module_exit()
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
CVE-2021-47357
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mcb: fix error handling in mcb_alloc_bus()
There are two bugs:
1) If ida_simple_get() fails then this code calls put_device(carrier)
but we haven't yet called get_device(carrier) and probably that
leads to a use after free.
2) After device_initialize() then we need to use put_device() to
release the bus. This will free the internal resources tied to the
device and call mcb_free_bus() which will free the rest.
CVE-2021-47361
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Update intermediate power state for SI
Update the current state as boot state during dpm initialization.
During the subsequent initialization, set_power_state gets called to
transition to the final power state. set_power_state refers to values
from the current state and without current state populated, it could
result in NULL pointer dereference.
For ex: on platforms where PCI speed change is supported through ACPI
ATCS method, the link speed of current state needs to be queried before
deciding on changing to final power state's link speed. The logic to query
ATCS-support was broken on certain platforms. The issue became visible
when broken ATCS-support logic got fixed with commit
f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698
CVE-2021-47362
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: fix NULL deref in qeth_clear_working_pool_list()
When qeth_set_online() calls qeth_clear_working_pool_list() to roll
back after an error exit from qeth_hardsetup_card(), we are at risk of
accessing card->qdio.in_q before it was allocated by
qeth_alloc_qdio_queues() via qeth_mpc_initialize().
qeth_clear_working_pool_list() then dereferences NULL, and by writing to
queue->bufs[i].pool_entry scribbles all over the CPU's lowcore.
Resulting in a crash when those lowcore areas are used next (eg. on
the next machine-check interrupt).
Such a scenario would typically happen when the device is first set
online and its queues aren't allocated yet. An early IO error or certain
misconfigs (eg. mismatched transport mode, bad portno) then cause us to
error out from qeth_hardsetup_card() with card->qdio.in_q still being
NULL.
Fix it by checking the pointer for NULL before accessing it.
Note that we also have (rare) paths inside qeth_mpc_initialize() where
a configuration change can cause us to free the existing queues,
expecting that subsequent code will allocate them again. If we then
error out before that re-allocation happens, the same bug occurs.
Root-caused-by: Heiko Carstens <hca@linux.ibm.com>
CVE-2021-47369
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix use after free on rmmod
plat_dev->dev->platform_data is released by platform_device_unregister(),
use of pclk and hclk is a use-after-free. Since device unregister won't
need a clk device we adjust the function call sequence to fix this issue.
[ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]
[ 31.275563] Freed by task 306:
[ 30.276782] platform_device_release+0x25/0x80
CVE-2021-47372
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3-its: Fix potential VPE leak on error
In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,
there is an off-by-one in the number of VPEs to be freed.
Fix it by simply passing the number of VPEs allocated, which is the
index of the loop iterating over the VPEs.
[maz: fixed commit message]
CVE-2021-47373
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
blktrace: Fix uaf in blk_trace access after removing by sysfs
There is an use-after-free problem triggered by following process:
P1(sda) P2(sdb)
echo 0 > /sys/block/sdb/trace/enable
blk_trace_remove_queue
synchronize_rcu
blk_trace_free
relay_close
rcu_read_lock
__blk_add_trace
trace_note_tsk
(Iterate running_trace_list)
relay_close_buf
relay_destroy_buf
kfree(buf)
trace_note(sdb's bt)
relay_reserve
buf->offset <- nullptr deference (use-after-free) !!!
rcu_read_unlock
[ 502.714379] BUG: kernel NULL pointer dereference, address:
0000000000000010
[ 502.715260] #PF: supervisor read access in kernel mode
[ 502.715903] #PF: error_code(0x0000) - not-present page
[ 502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0
[ 502.717252] Oops: 0000 [#1] SMP
[ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360
[ 502.732872] Call Trace:
[ 502.733193] __blk_add_trace.cold+0x137/0x1a3
[ 502.733734] blk_add_trace_rq+0x7b/0xd0
[ 502.734207] blk_add_trace_rq_issue+0x54/0xa0
[ 502.734755] blk_mq_start_request+0xde/0x1b0
[ 502.735287] scsi_queue_rq+0x528/0x1140
...
[ 502.742704] sg_new_write.isra.0+0x16e/0x3e0
[ 502.747501] sg_ioctl+0x466/0x1100
Reproduce method:
ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])
ioctl(/dev/sda, BLKTRACESTART)
ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])
ioctl(/dev/sdb, BLKTRACESTART)
echo 0 > /sys/block/sdb/trace/enable &
// Add delay(mdelay/msleep) before kernel enters blk_trace_free()
ioctl$SG_IO(/dev/sda, SG_IO, ...)
// Enters trace_note_tsk() after blk_trace_free() returned
// Use mdelay in rcu region rather than msleep(which may schedule out)
Remove blk_trace from running_list before calling blk_trace_free() by
sysfs if blk_trace is at Blktrace_running state.
CVE-2021-47375
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nvme-rdma: destroy cm id before destroy qp to avoid use after free
We should always destroy cm_id before destroy qp to avoid to get cma
event after qp was destroyed, which may lead to use after free.
In RDMA connection establishment error flow, don't destroy qp in cm
event handler.Just report cm_error to upper level, qp will be destroy
in nvme_rdma_alloc_queue() after destroy cm id.
CVE-2021-47378
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pd
KASAN reports a use-after-free report when doing fuzz test:
[693354.104835] ==================================================================
[693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160
[693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338
[693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147
[693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018
[693354.105612] Call Trace:
[693354.105621] dump_stack+0xf1/0x19b
[693354.105626] ? show_regs_print_info+0x5/0x5
[693354.105634] ? printk+0x9c/0xc3
[693354.105638] ? cpumask_weight+0x1f/0x1f
[693354.105648] print_address_description+0x70/0x360
[693354.105654] kasan_report+0x1b2/0x330
[693354.105659] ? bfq_io_set_weight_legacy+0xd3/0x160
[693354.105665] ? bfq_io_set_weight_legacy+0xd3/0x160
[693354.105670] bfq_io_set_weight_legacy+0xd3/0x160
[693354.105675] ? bfq_cpd_init+0x20/0x20
[693354.105683] cgroup_file_write+0x3aa/0x510
[693354.105693] ? ___slab_alloc+0x507/0x540
[693354.105698] ? cgroup_file_poll+0x60/0x60
[693354.105702] ? 0xffffffff89600000
[693354.105708] ? usercopy_abort+0x90/0x90
[693354.105716] ? mutex_lock+0xef/0x180
[693354.105726] kernfs_fop_write+0x1ab/0x280
[693354.105732] ? cgroup_file_poll+0x60/0x60
[693354.105738] vfs_write+0xe7/0x230
[693354.105744] ksys_write+0xb0/0x140
[693354.105749] ? __ia32_sys_read+0x50/0x50
[693354.105760] do_syscall_64+0x112/0x370
[693354.105766] ? syscall_return_slowpath+0x260/0x260
[693354.105772] ? do_page_fault+0x9b/0x270
[693354.105779] ? prepare_exit_to_usermode+0xf9/0x1a0
[693354.105784] ? enter_from_user_mode+0x30/0x30
[693354.105793] entry_SYSCALL_64_after_hwframe+0x65/0xca
[693354.105875] Allocated by task 1453337:
[693354.106001] kasan_kmalloc+0xa0/0xd0
[693354.106006] kmem_cache_alloc_node_trace+0x108/0x220
[693354.106010] bfq_pd_alloc+0x96/0x120
[693354.106015] blkcg_activate_policy+0x1b7/0x2b0
[693354.106020] bfq_create_group_hierarchy+0x1e/0x80
[693354.106026] bfq_init_queue+0x678/0x8c0
[693354.106031] blk_mq_init_sched+0x1f8/0x460
[693354.106037] elevator_switch_mq+0xe1/0x240
[693354.106041] elevator_switch+0x25/0x40
[693354.106045] elv_iosched_store+0x1a1/0x230
[693354.106049] queue_attr_store+0x78/0xb0
[693354.106053] kernfs_fop_write+0x1ab/0x280
[693354.106056] vfs_write+0xe7/0x230
[693354.106060] ksys_write+0xb0/0x140
[693354.106064] do_syscall_64+0x112/0x370
[693354.106069] entry_SYSCALL_64_after_hwframe+0x65/0xca
[693354.106114] Freed by task 1453336:
[693354.106225] __kasan_slab_free+0x130/0x180
[693354.106229] kfree+0x90/0x1b0
[693354.106233] blkcg_deactivate_policy+0x12c/0x220
[693354.106238] bfq_exit_queue+0xf5/0x110
[693354.106241] blk_mq_exit_sched+0x104/0x130
[693354.106245] __elevator_exit+0x45/0x60
[693354.106249] elevator_switch_mq+0xd6/0x240
[693354.106253] elevator_switch+0x25/0x40
[693354.106257] elv_iosched_store+0x1a1/0x230
[693354.106261] queue_attr_store+0x78/0xb0
[693354.106264] kernfs_fop_write+0x1ab/0x280
[693354.106268] vfs_write+0xe7/0x230
[693354.106271] ksys_write+0xb0/0x140
[693354.106275] do_syscall_64+0x112/0x370
[693354.106280] entry_SYSCALL_64_after_hwframe+0x65/0xca
[693354.106329] The buggy address belongs to the object at ffff888be0a35580
which belongs to the cache kmalloc-1k of size 1024
[693354.106736] The buggy address is located 228 bytes inside of
1024-byte region [ffff888be0a35580, ffff888be0a35980)
[693354.107114] The buggy address belongs to the page:
[693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0
[693354.107606] flags: 0x17ffffc0008100(slab|head)
[693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080
[693354.108020] r
---truncated---
CVE-2021-47379
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: fix deadlock during failing recovery
Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed
taking discipline_mutex inside qeth_do_reset(), fixing potential
deadlocks. An error path was missed though, that still takes
discipline_mutex and thus has the original deadlock potential.
Intermittent deadlocks were seen when a qeth channel path is configured
offline, causing a race between qeth_do_reset and ccwgroup_remove.
Call qeth_set_offline() directly in the qeth_do_reset() error case and
then a new variant of ccwgroup_set_offline(), without taking
discipline_mutex.
CVE-2021-47382
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: Fix out-of-bound vmalloc access in imageblit
This issue happens when a userspace program does an ioctl
FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct
containing only the fields xres, yres, and bits_per_pixel
with values.
If this struct is the same as the previous ioctl, the
vc_resize() detects it and doesn't call the resize_screen(),
leaving the fb_var_screeninfo incomplete. And this leads to
the updatescrollmode() calculates a wrong value to
fbcon_display->vrows, which makes the real_y() return a
wrong value of y, and that value, eventually, causes
the imageblit to access an out-of-bound address value.
To solve this issue I made the resize_screen() be called
even if the screen does not need any resizing, so it will
"fix and fill" the fb_var_screeninfo independently.
CVE-2021-47383
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: schedutil: Use kobject release() method to free sugov_tunables
The struct sugov_tunables is protected by the kobject, so we can't free
it directly. Otherwise we would get a call trace like this:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30
WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
Modules linked in:
CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507
Hardware name: Marvell OcteonTX CN96XX board (DT)
pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
pc : debug_print_object+0xb8/0x100
lr : debug_print_object+0xb8/0x100
sp : ffff80001ecaf910
x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80
x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000
x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20
x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010
x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365
x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69
x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0
x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001
x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000
x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000
Call trace:
debug_print_object+0xb8/0x100
__debug_check_no_obj_freed+0x1c0/0x230
debug_check_no_obj_freed+0x20/0x88
slab_free_freelist_hook+0x154/0x1c8
kfree+0x114/0x5d0
sugov_exit+0xbc/0xc0
cpufreq_exit_governor+0x44/0x90
cpufreq_set_policy+0x268/0x4a8
store_scaling_governor+0xe0/0x128
store+0xc0/0xf0
sysfs_kf_write+0x54/0x80
kernfs_fop_write_iter+0x128/0x1c0
new_sync_write+0xf0/0x190
vfs_write+0x2d4/0x478
ksys_write+0x74/0x100
__arm64_sys_write+0x24/0x30
invoke_syscall.constprop.0+0x54/0xe0
do_el0_svc+0x64/0x158
el0_svc+0x2c/0xb0
el0t_64_sync_handler+0xb0/0xb8
el0t_64_sync+0x198/0x19c
irq event stamp: 5518
hardirqs last enabled at (5517): [<ffff8000100cbd7c>] console_unlock+0x554/0x6c8
hardirqs last disabled at (5518): [<ffff800010fc0638>] el1_dbg+0x28/0xa0
softirqs last enabled at (5504): [<ffff8000100106e0>] __do_softirq+0x4d0/0x6c0
softirqs last disabled at (5483): [<ffff800010049548>] irq_exit+0x1b0/0x1b8
So split the original sugov_tunables_free() into two functions,
sugov_clear_global_tunables() is just used to clear the global_tunables
and the new sugov_tunables_free() is used as kobj_type::release to
release the sugov_tunables safely.
CVE-2021-47387
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix use-after-free in CCMP/GCMP RX
When PN checking is done in mac80211, for fragmentation we need
to copy the PN to the RX struct so we can later use it to do a
comparison, since commit bf30ca922a0c ("mac80211: check defrag
PN against current frame").
Unfortunately, in that commit I used the 'hdr' variable without
it being necessarily valid, so use-after-free could occur if it
was necessary to reallocate (parts of) the frame.
Fix this by reloading the variable after the code that results
in the reallocations, if any.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.
CVE-2021-47388
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
on the same id_priv. While this cannot happen without going through the
work, it violates the invariant that the same address resolution
background request cannot be active twice.
CPU 1 CPU 2
rdma_resolve_addr():
RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY
rdma_resolve_ip(addr_handler) #1
process_one_req(): for #1
addr_handler():
RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND
mutex_unlock(&id_priv->handler_mutex);
[.. handler still running ..]
rdma_resolve_addr():
RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY
rdma_resolve_ip(addr_handler)
!! two requests are now on the req_list
rdma_destroy_id():
destroy_id_handler_unlock():
_destroy_id():
cma_cancel_operation():
rdma_addr_cancel()
// process_one_req() self removes it
spin_lock_bh(&lock);
cancel_delayed_work(&req->work);
if (!list_empty(&req->list)) == true
! rdma_addr_cancel() returns after process_on_req #1 is done
kfree(id_priv)
process_one_req(): for #2
addr_handler():
mutex_lock(&id_priv->handler_mutex);
!! Use after free on id_priv
rdma_addr_cancel() expects there to be one req on the list and only
cancels the first one. The self-removal behavior of the work only happens
after the handler has returned. This yields a situations where the
req_list can have two reqs for the same "handle" but rdma_addr_cancel()
only cancels the first one.
The second req remains active beyond rdma_destroy_id() and will
use-after-free id_priv once it inevitably triggers.
Fix this by remembering if the id_priv has called rdma_resolve_ip() and
always cancel before calling it again. This ensures the req_list never
gets more than one item in it and doesn't cost anything in the normal flow
that never uses this strange error path.
CVE-2021-47391
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap
Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap
routine in order to fix the following warning reported by syzbot:
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
Modules linked in:
CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216
RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000
RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100
R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8
R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004
FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740
netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089
__dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165
__bpf_tx_skb net/core/filter.c:2114 [inline]
__bpf_redirect_no_mac net/core/filter.c:2139 [inline]
__bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162
____bpf_clone_redirect net/core/filter.c:2429 [inline]
bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401
bpf_prog_eeb6f53a69e5c6a2+0x59/0x234
bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]
__bpf_prog_run include/linux/filter.h:624 [inline]
bpf_prog_run include/linux/filter.h:631 [inline]
bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119
bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663
bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]
__sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605
__do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
__se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
__x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665f9
CVE-2021-47395
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
We should always check if skb_header_pointer's return is NULL before
using it, otherwise it may cause null-ptr-deref, as syzbot reported:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]
RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196
Call Trace:
<IRQ>
sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109
ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422
ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463
NF_HOOK include/linux/netfilter.h:307 [inline]
NF_HOOK include/linux/netfilter.h:301 [inline]
ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472
dst_input include/net/dst.h:460 [inline]
ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]
NF_HOOK include/linux/netfilter.h:307 [inline]
NF_HOOK include/linux/netfilter.h:301 [inline]
ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297
CVE-2021-47397
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup
The ixgbe driver currently generates a NULL pointer dereference with
some machine (online cpus < 63). This is due to the fact that the
maximum value of num_xdp_queues is nr_cpu_ids. Code is in
"ixgbe_set_rss_queues"".
Here's how the problem repeats itself:
Some machine (online cpus < 63), And user set num_queues to 63 through
ethtool. Code is in the "ixgbe_set_channels",
adapter->ring_feature[RING_F_FDIR].limit = count;
It becomes 63.
When user use xdp, "ixgbe_set_rss_queues" will set queues num.
adapter->num_rx_queues = rss_i;
adapter->num_tx_queues = rss_i;
adapter->num_xdp_queues = ixgbe_xdp_queues(adapter);
And rss_i's value is from
f = &adapter->ring_feature[RING_F_FDIR];
rss_i = f->indices = f->limit;
So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup",
for (i = 0; i < adapter->num_rx_queues; i++)
if (adapter->xdp_ring[i]->xsk_umem)
It leads to panic.
Call trace:
[exception RIP: ixgbe_xdp+368]
RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297
RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90
RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000
R10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000
R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc
8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808
9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235
10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384
11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd
12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb
13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88
14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319
15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290
16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8
17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64
18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9
19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c
So I fix ixgbe_max_channels so that it will not allow a setting of queues
to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,
take the smaller value of num_rx_queues and num_xdp_queues.
CVE-2021-47399
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: do not allow call hns3_nic_net_open repeatedly
hns3_nic_net_open() is not allowed to called repeatly, but there
is no checking for this. When doing device reset and setup tc
concurrently, there is a small oppotunity to call hns3_nic_net_open
repeatedly, and cause kernel bug by calling napi_enable twice.
The calltrace information is like below:
[ 3078.222780] ------------[ cut here ]------------
[ 3078.230255] kernel BUG at net/core/dev.c:6991!
[ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)
[ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1
[ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021
[ 3078.276801] Workqueue: hclge hclge_service_task [hclge]
[ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 3078.296168] pc : napi_enable+0x80/0x84
tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3]
[ 3078.314771] sp : ffff8000108abb20
[ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300
[ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000
[ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880
[ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000
[ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930
[ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4
[ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8
[ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344
[ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938
[ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0
[ 3078.414657] Call trace:
[ 3078.418517] napi_enable+0x80/0x84
[ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3]
[ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3]
[ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge]
[ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge]
[ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge]
[ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge]
[ 3078.475675] process_one_work+0x1dc/0x48c
[ 3078.481888] worker_thread+0x15c/0x464
[ 3078.487104] kthread+0x160/0x170
[ 3078.492479] ret_from_fork+0x10/0x18
[ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000)
[ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---
Once hns3_nic_net_open() is excute success, the flag
HNS3_NIC_STATE_DOWN will be cleared. So add checking for this
flag, directly return when HNS3_NIC_STATE_DOWN is no set.
CVE-2021-47400
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipack: ipoctal: fix stack information leak
The tty driver name is used also after registering the driver and must
specifically not be allocated on the stack to avoid leaking information
to user space (or triggering an oops).
Drivers should not try to encode topology information in the tty device
name but this one snuck in through staging without anyone noticing and
another driver has since copied this malpractice.
Fixing the ABI is a separate issue, but this at least plugs the security
hole.
CVE-2021-47401
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipack: ipoctal: fix module reference leak
A reference to the carrier module was taken on every open but was only
released once when the final reference to the tty struct was dropped.
Fix this by taking the module reference and initialising the tty driver
data when installing the tty.
CVE-2021-47403
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: betop: fix slab-out-of-bounds Write in betop_probe
Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.
The problem is the driver assumes the device must have an input report but
some malicious devices violate this assumption.
So this patch checks hid_device's input is non empty before it's been used.
CVE-2021-47404
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: free raw_report buffers in usbhid_stop
Free the unsent raw_report buffers when the device is removed.
Fixes a memory leak reported by syzbot at:
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47
CVE-2021-47405
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Handle SRCU initialization failure during page track init
Check the return of init_srcu_struct(), which can fail due to OOM, when
initializing the page track mechanism. Lack of checking leads to a NULL
pointer deref found by a modified syzkaller.
[Move the call towards the beginning of kvm_arch_init_vm. - Paolo]
CVE-2021-47407
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVE-2021-47409
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
phy: mdio: fix memory leak
Syzbot reported memory leak in MDIO bus interface, the problem was in
wrong state logic.
MDIOBUS_ALLOCATED indicates 2 states:
1. Bus is only allocated
2. Bus allocated and __mdiobus_register() fails, but
device_register() was called
In case of device_register() has been called we should call put_device()
to correctly free the memory allocated for this device, but mdiobus_free()
calls just kfree(dev) in case of MDIOBUS_ALLOCATED state
To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED
_before_ calling device_register(), because put_device() should be
called even in case of device_register() failure.
CVE-2021-47416
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
net_sched: fix NULL deref in fifo_set_limit()
syzbot reported another NULL deref in fifo_set_limit() [1]
I could repro the issue with :
unshare -n
tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit
tc qd replace dev lo parent 1:0 pfifo_fast
tc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit
pfifo_fast does not have a change() operation.
Make fifo_set_limit() more robust about this.
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0
Oops: 0010 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:0x0
Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000
RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910
R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800
FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
fifo_set_limit net/sched/sch_fifo.c:242 [inline]
fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227
tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418
qdisc_change net/sched/sch_api.c:1332 [inline]
tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634
rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
___sys_sendmsg+0xf3/0x170 net/socket.c:2463
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-47418
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/debugfs: fix file release memory leak
When using single_open() for opening, single_release() should be
called, otherwise the 'op' allocated in single_open() will be leaked.
CVE-2021-47423
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix freeing of uninitialized misc IRQ vector
When VSI set up failed in i40e_probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e_clear_interrupt_scheme and produced a kernel Oops:
Trying to free already-free IRQ 266
WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
Workqueue: events work_for_cpu_fn
RIP: 0010:__free_irq+0x9a/0x300
Call Trace:
? synchronize_irq+0x3a/0xa0
free_irq+0x2e/0x60
i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
i40e_probe.part.108+0x134b/0x1a40 [i40e]
? kmem_cache_alloc+0x158/0x1c0
? acpi_ut_update_ref_count.part.1+0x8e/0x345
? acpi_ut_update_object_reference+0x15e/0x1e2
? strstr+0x21/0x70
? irq_get_irq_data+0xa/0x20
? mp_check_pin_attr+0x13/0xc0
? irq_get_irq_data+0xa/0x20
? mp_map_pin_to_irq+0xd3/0x2f0
? acpi_register_gsi_ioapic+0x93/0x170
? pci_conf1_read+0xa4/0x100
? pci_bus_read_config_word+0x49/0x70
? do_pci_enable_device+0xcc/0x100
local_pci_probe+0x41/0x90
work_for_cpu_fn+0x16/0x20
process_one_work+0x1a7/0x360
worker_thread+0x1cf/0x390
? create_worker+0x1a0/0x1a0
kthread+0x112/0x130
? kthread_flush_work_fn+0x10/0x10
ret_from_fork+0x1f/0x40
The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.
Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED
PF state before calling i40e_free_misc_vector. This state is set only if
misc IRQ vectors were properly initialized.
CVE-2021-47424
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: acpi: fix resource leak in reconfiguration device addition
acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a
reference on the adapter which is never released which will result in a
reference count leak and render the adapter unremovable. Make sure to
put the adapter after creating the client in the same manner that we do
for OF.
[wsa: fixed title]
CVE-2021-47425
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix gart.bo pin_count leak
gmc_v{9,10}_0_gart_disable() isn't called matched with
correspoding gart_enbale function in SRIOV case. This will
lead to gart.bo pin_count leak on driver unload.
CVE-2021-47431
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix command ring pointer corruption while aborting a command
The command ring pointer is located at [6:63] bits of the command
ring control register (CRCR). All the control bits like command stop,
abort are located at [0:3] bits. While aborting a command, we read the
CRCR and set the abort bit and write to the CRCR. The read will always
give command ring pointer as all zeros. So we essentially write only
the control bits. Since we split the 64 bit write into two 32 bit writes,
there is a possibility of xHC command ring stopped before the upper
dword (all zeros) is written. If that happens, xHC updates the upper
dword of its internal command ring pointer with all zeros. Next time,
when the command ring is restarted, we see xHC memory access failures.
Fix this issue by only writing to the lower dword of CRCR where all
control bits are located.
CVE-2021-47434
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm: fix mempool NULL pointer race when completing IO
dm_io_dec_pending() calls end_io_acct() first and will then dec md
in-flight pending count. But if a task is swapping DM table at same
time this can result in a crash due to mempool->elements being NULL:
task1 task2
do_resume
->do_suspend
->dm_wait_for_completion
bio_endio
->clone_endio
->dm_io_dec_pending
->end_io_acct
->wakeup task1
->dm_swap_table
->__bind
->__bind_mempools
->bioset_exit
->mempool_exit
->free_io
[ 67.330330] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
......
[ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO)
[ 67.330510] pc : mempool_free+0x70/0xa0
[ 67.330515] lr : mempool_free+0x4c/0xa0
[ 67.330520] sp : ffffff8008013b20
[ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004
[ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8
[ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800
[ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800
[ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80
[ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c
[ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd
[ 67.330563] x15: 000000000093b41e x14: 0000000000000010
[ 67.330569] x13: 0000000000007f7a x12: 0000000034155555
[ 67.330574] x11: 0000000000000001 x10: 0000000000000001
[ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000
[ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a
[ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001
[ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8
[ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970
[ 67.330609] Call trace:
[ 67.330616] mempool_free+0x70/0xa0
[ 67.330627] bio_put+0xf8/0x110
[ 67.330638] dec_pending+0x13c/0x230
[ 67.330644] clone_endio+0x90/0x180
[ 67.330649] bio_endio+0x198/0x1b8
[ 67.330655] dec_pending+0x190/0x230
[ 67.330660] clone_endio+0x90/0x180
[ 67.330665] bio_endio+0x198/0x1b8
[ 67.330673] blk_update_request+0x214/0x428
[ 67.330683] scsi_end_request+0x2c/0x300
[ 67.330688] scsi_io_completion+0xa0/0x710
[ 67.330695] scsi_finish_command+0xd8/0x110
[ 67.330700] scsi_softirq_done+0x114/0x148
[ 67.330708] blk_done_softirq+0x74/0xd0
[ 67.330716] __do_softirq+0x18c/0x374
[ 67.330724] irq_exit+0xb4/0xb8
[ 67.330732] __handle_domain_irq+0x84/0xc0
[ 67.330737] gic_handle_irq+0x148/0x1b0
[ 67.330744] el1_irq+0xe8/0x190
[ 67.330753] lpm_cpuidle_enter+0x4f8/0x538
[ 67.330759] cpuidle_enter_state+0x1fc/0x398
[ 67.330764] cpuidle_enter+0x18/0x20
[ 67.330772] do_idle+0x1b4/0x290
[ 67.330778] cpu_startup_entry+0x20/0x28
[ 67.330786] secondary_start_kernel+0x160/0x170
Fix this by:
1) Establishing pointers to 'struct dm_io' members in
dm_io_dec_pending() so that they may be passed into end_io_acct()
_after_ free_io() is called.
2) Moving end_io_acct() after free_io().
CVE-2021-47435
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: musb: dsps: Fix the probe error path
Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after
initializing musb") has inverted the calls to
dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without
updating correctly the error path. dsps_create_musb_pdev() allocates and
registers a new platform device which must be unregistered and freed
with platform_device_unregister(), and this is missing upon
dsps_setup_optional_vbus_irq() error.
While on the master branch it seems not to trigger any issue, I observed
a kernel crash because of a NULL pointer dereference with a v5.10.70
stable kernel where the patch mentioned above was backported. With this
kernel version, -EPROBE_DEFER is returned the first time
dsps_setup_optional_vbus_irq() is called which triggers the probe to
error out without unregistering the platform device. Unfortunately, on
the Beagle Bone Black Wireless, the platform device still living in the
system is being used by the USB Ethernet gadget driver, which during the
boot phase triggers the crash.
My limited knowledge of the musb world prevents me to revert this commit
which was sent to silence a robot warning which, as far as I understand,
does not make sense. The goal of this patch was to prevent an IRQ to
fire before the platform device being registered. I think this cannot
ever happen due to the fact that enabling the interrupts is done by the
->enable() callback of the platform musb device, and this platform
device must be already registered in order for the core or any other
user to use this callback.
Hence, I decided to fix the error path, which might prevent future
errors on mainline kernels while also fixing older ones.
CVE-2021-47436
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
Prior to this patch in case mlx5_core_destroy_cq() failed it returns
without completing all destroy operations and that leads to memory leak.
Instead, complete the destroy flow before return error.
Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()
to be symmetrical with mlx5_core_create_cq().
kmemleak complains on:
unreferenced object 0xc000000038625100 (size 64):
comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s)
hex dump (first 32 bytes):
60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....
02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....
backtrace:
[<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core]
[<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]
[<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]
[<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]
[<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core]
[<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]
[<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]
[<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230
[mlx5_core]
[<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300
[mlx5_core]
[<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]
[<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]
[<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0
[<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0
[<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0
[<00000000646c5c2c>] genl_rcv_msg+0x78/0x120
[<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0
CVE-2021-47438
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: thermal: Fix out-of-bounds memory accesses
Currently, mlxsw allows cooling states to be set above the maximum
cooling state supported by the driver:
# cat /sys/class/thermal/thermal_zone2/cdev0/type
mlxsw_fan
# cat /sys/class/thermal/thermal_zone2/cdev0/max_state
10
# echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state
# echo $?
0
This results in out-of-bounds memory accesses when thermal state
transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the
transition table is accessed with a too large index (state) [1].
According to the thermal maintainer, it is the responsibility of the
driver to reject such operations [2].
Therefore, return an error when the state to be set exceeds the maximum
cooling state supported by the driver.
To avoid dead code, as suggested by the thermal maintainer [3],
partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling
device with cooling levels") that tried to interpret these invalid
cooling states (above the maximum) in a special way. The cooling levels
array is not removed in order to prevent the fans going below 20% PWM,
which would cause them to get stuck at 0% PWM.
[1]
BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290
Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122
Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016
Workqueue: events_freezable_power_ thermal_zone_device_check
Call Trace:
dump_stack_lvl+0x8b/0xb3
print_address_description.constprop.0+0x1f/0x140
kasan_report.cold+0x7f/0x11b
thermal_cooling_device_stats_update+0x271/0x290
__thermal_cdev_update+0x15e/0x4e0
thermal_cdev_update+0x9f/0xe0
step_wise_throttle+0x770/0xee0
thermal_zone_device_update+0x3f6/0xdf0
process_one_work+0xa42/0x1770
worker_thread+0x62f/0x13e0
kthread+0x3ee/0x4e0
ret_from_fork+0x1f/0x30
Allocated by task 1:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x7c/0x90
thermal_cooling_device_setup_sysfs+0x153/0x2c0
__thermal_cooling_device_register.part.0+0x25b/0x9c0
thermal_cooling_device_register+0xb3/0x100
mlxsw_thermal_init+0x5c5/0x7e0
__mlxsw_core_bus_device_register+0xcb3/0x19c0
mlxsw_core_bus_device_register+0x56/0xb0
mlxsw_pci_probe+0x54f/0x710
local_pci_probe+0xc6/0x170
pci_device_probe+0x2b2/0x4d0
really_probe+0x293/0xd10
__driver_probe_device+0x2af/0x440
driver_probe_device+0x51/0x1e0
__driver_attach+0x21b/0x530
bus_for_each_dev+0x14c/0x1d0
bus_add_driver+0x3ac/0x650
driver_register+0x241/0x3d0
mlxsw_sp_module_init+0xa2/0x174
do_one_initcall+0xee/0x5f0
kernel_init_freeable+0x45a/0x4de
kernel_init+0x1f/0x210
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff8881052f7800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 1016 bytes inside of
1024-byte region [ffff8881052f7800, ffff8881052f7c00)
The buggy address belongs to the page:
page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0
head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-
---truncated---
CVE-2021-47441
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix null pointer dereference on pointer edp
The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.
Addresses-Coverity: ("Dereference before null check")
CVE-2021-47445
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ptp: Fix possible memory leak in ptp_clock_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88800906c618 (size 8):
comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s)
hex dump (first 8 bytes):
70 74 70 30 00 00 00 00 ptp0....
backtrace:
[<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0
[<0000000079f6e2ff>] kvasprintf+0xb5/0x150
[<0000000026aae54f>] kvasprintf_const+0x60/0x190
[<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150
[<000000004e35abdd>] dev_set_name+0xc0/0x100
[<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp]
[<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
When posix_clock_register() returns an error, the name allocated
in dev_set_name() will be leaked, the put_device() should be used
to give up the device reference, then the name will be freed in
kobject_cleanup() and other memory will be freed in ptp_clock_release().
CVE-2021-47455
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: peak_pci: peak_pci_remove(): fix UAF
When remove the module peek_pci, referencing 'chan' again after
releasing 'dev' will cause UAF.
Fix this by releasing 'dev' later.
The following log reveals it:
[ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci]
[ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537
[ 35.965513 ] Call Trace:
[ 35.965718 ] dump_stack_lvl+0xa8/0xd1
[ 35.966028 ] print_address_description+0x87/0x3b0
[ 35.966420 ] kasan_report+0x172/0x1c0
[ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]
[ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170
[ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]
[ 35.967945 ] __asan_report_load8_noabort+0x14/0x20
[ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci]
[ 35.968752 ] pci_device_remove+0xa9/0x250
CVE-2021-47456
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: mount fails with buffer overflow in strlen
Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an
ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the
trace below. Problem seems to be that strings for cluster stack and
cluster name are not guaranteed to be null terminated in the disk
representation, while strlcpy assumes that the source string is always
null terminated. This causes a read outside of the source string
triggering the buffer overflow detection.
detected buffer overflow in strlen
------------[ cut here ]------------
kernel BUG at lib/string.c:1149!
invalid opcode: 0000 [#1] SMP PTI
CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1
Debian 5.14.6-2
RIP: 0010:fortify_panic+0xf/0x11
...
Call Trace:
ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]
ocfs2_fill_super+0x359/0x19b0 [ocfs2]
mount_bdev+0x185/0x1b0
legacy_get_tree+0x27/0x40
vfs_get_tree+0x25/0xb0
path_mount+0x454/0xa20
__x64_sys_mount+0x103/0x140
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-47458
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after conversion from inline format
Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in
block_write_full_page()") uncovered a latent bug in ocfs2 conversion
from inline inode format to a normal inode format.
The code in ocfs2_convert_inline_data_to_extents() attempts to zero out
the whole cluster allocated for file data by grabbing, zeroing, and
dirtying all pages covering this cluster. However these pages are
beyond i_size, thus writeback code generally ignores these dirty pages
and no blocks were ever actually zeroed on the disk.
This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero
pages past i_size.") for standard ocfs2 write path, inline conversion
path was apparently forgotten; the commit log also has a reasoning why
the zeroing actually is not needed.
After commit 6dbf7bb55598, things became worse as writeback code stopped
invalidating buffers on pages beyond i_size and thus these pages end up
with clean PageDirty bit but with buffers attached to these pages being
still dirty. So when a file is converted from inline format, then
writeback triggers, and then the file is grown so that these pages
become valid, the invalid dirtiness state is preserved,
mark_buffer_dirty() does nothing on these pages (buffers are already
dirty) but page is never written back because it is clean. So data
written to these pages is lost once pages are reclaimed.
Simple reproducer for the problem is:
xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \
-c "pwrite 4000 2000" ocfs2_file
After unmounting and mounting the fs again, you can observe that end of
'ocfs2_file' has lost its contents.
Fix the problem by not doing the pointless zeroing during conversion
from inline format similarly as in the standard write path.
[akpm@linux-foundation.org: fix whitespace, per Joseph]
CVE-2021-47460
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: Fix sleeping function called from invalid context
The driver can call card->isac.release() function from an atomic
context.
Fix this by calling this function after releasing the lock.
The following log reveals it:
[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
[ 44.169574 ] INFO: lockdep is turned off.
[ 44.169899 ] irq event stamp: 0
[ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00
[ 44.171240 ] softirqs last enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00
[ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 44.172318 ] Preemption disabled at:
[ 44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet]
[ 44.174441 ] Call Trace:
[ 44.174630 ] dump_stack_lvl+0xa8/0xd1
[ 44.174912 ] dump_stack+0x15/0x17
[ 44.175166 ] ___might_sleep+0x3a2/0x510
[ 44.175459 ] ? nj_release+0x69/0x500 [netjet]
[ 44.175791 ] __might_sleep+0x82/0xe0
[ 44.176063 ] ? start_flush_work+0x20/0x7b0
[ 44.176375 ] start_flush_work+0x33/0x7b0
[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170
[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0
[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0
[ 44.177711 ] __flush_work+0x11a/0x1a0
[ 44.177991 ] ? flush_work+0x20/0x20
[ 44.178257 ] ? lock_release+0x13c/0x8f0
[ 44.178550 ] ? __kasan_check_write+0x14/0x20
[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360
[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20
[ 44.179530 ] ? __kasan_check_read+0x11/0x20
[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900
[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140
[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60
[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0
[ 44.181189 ] ? kfree+0x13e/0x290
[ 44.181438 ] flush_work+0x17/0x20
[ 44.181695 ] mISDN_freedchannel+0xe8/0x100
[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac]
[ 44.182366 ] nj_release+0xf6/0x500 [netjet]
[ 44.182685 ] nj_remove+0x48/0x70 [netjet]
[ 44.182989 ] pci_device_remove+0xa9/0x250
CVE-2021-47468
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2021-47469
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2021-47472
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of
qla2x00_process_els()"), intended to change:
bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN
bsg_job->request->msgcode != FC_BSG_RPT_ELS
but changed it to:
bsg_job->request->msgcode == FC_BSG_RPT_ELS
instead.
Change the == to a != to avoid leaking the fcport structure or freeing
unallocated memory.
CVE-2021-47473
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
isofs: Fix out of bound access for corrupted isofs image
When isofs image is suitably corrupted isofs_read_inode() can read data
beyond the end of buffer. Sanity-check the directory entry length before
using it.
CVE-2021-47478
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Put LLD module refcnt after SCSI device is released
SCSI host release is triggered when SCSI device is freed. We have to make
sure that the low-level device driver module won't be unloaded before SCSI
host instance is released because shost->hostt is required in the release
handler.
Make sure to put LLD module refcnt after SCSI device is released.
Fixes a kernel panic of 'BUG: unable to handle page fault for address'
reported by Changhui and Yi.
CVE-2021-47480
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
regmap: Fix possible double-free in regcache_rbtree_exit()
In regcache_rbtree_insert_to_block(), when 'present' realloc failed,
the 'blk' which is supposed to assign to 'rbnode->block' will be freed,
so 'rbnode->block' points a freed memory, in the error handling path of
regcache_rbtree_init(), 'rbnode->block' will be freed again in
regcache_rbtree_exit(), KASAN will report double-free as follows:
BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
Call Trace:
slab_free_freelist_hook+0x10d/0x240
kfree+0xce/0x390
regcache_rbtree_exit+0x15d/0x1a0
regcache_rbtree_init+0x224/0x2c0
regcache_init+0x88d/0x1310
__regmap_init+0x3151/0x4a80
__devm_regmap_init+0x7d/0x100
madera_spi_probe+0x10f/0x333 [madera_spi]
spi_probe+0x183/0x210
really_probe+0x285/0xc30
To fix this, moving up the assignment of rbnode->block to immediately after
the reallocation has succeeded so that the data structure stays valid even
if the second reallocation fails.
CVE-2021-47483
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields
Overflowing either addrlimit or bytes_togo can allow userspace to trigger
a buffer overflow of kernel memory. Check for overflows in all the places
doing math on user controlled buffers.
CVE-2021-47485
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usbnet: sanity check for maxpacket
maxpacket of 0 makes no sense and oopses as we need to divide
by it. Give up.
V2: fixed typo in log and stylistic issues
CVE-2021-47495
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Fix flipped sign in tls_err_abort() calls
sk->sk_err appears to expect a positive value, a convention that ktls
doesn't always follow and that leads to memory corruption in other code.
For instance,
[kworker]
tls_encrypt_done(..., err=<negative error from crypto request>)
tls_err_abort(.., err)
sk->sk_err = err;
[task]
splice_from_pipe_feed
...
tls_sw_do_sendpage
if (sk->sk_err) {
ret = -sk->sk_err; // ret is positive
splice_from_pipe_feed (continued)
ret = actor(...) // ret is still positive and interpreted as bytes
// written, resulting in underflow of buf->len and
// sd->len, leading to huge buf->offset and bogus
// addresses computed in later calls to actor()
Fix all tls_err_abort() callers to pass a negative error code
consistently and centralize the error-prone sign flip there, throwing in
a warning to catch future misuse and uninlining the function so it
really does only warn once.
CVE-2021-47496
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
subtract one from that making a large number that is then shifted more than the
number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
shift exponent 64 is too large for 64-bit type 'unsigned long'
CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace+0x0/0x170
show_stack+0x24/0x30
dump_stack_lvl+0x64/0x7c
dump_stack+0x18/0x38
ubsan_epilogue+0x10/0x54
__ubsan_handle_shift_out_of_bounds+0x180/0x194
__nvmem_cell_read+0x1ec/0x21c
nvmem_cell_read+0x58/0x94
nvmem_cell_read_variable_common+0x4c/0xb0
nvmem_cell_read_variable_le_u32+0x40/0x100
a6xx_gpu_init+0x170/0x2f4
adreno_bind+0x174/0x284
component_bind_all+0xf0/0x264
msm_drm_bind+0x1d8/0x7a0
try_to_bring_up_master+0x164/0x1ac
__component_add+0xbc/0x13c
component_add+0x20/0x2c
dp_display_probe+0x340/0x384
platform_probe+0xc0/0x100
really_probe+0x110/0x304
__driver_probe_device+0xb8/0x120
driver_probe_device+0x4c/0xfc
__device_attach_driver+0xb0/0x128
bus_for_each_drv+0x90/0xdc
__device_attach+0xc8/0x174
device_initial_probe+0x20/0x2c
bus_probe_device+0x40/0xa4
deferred_probe_work_func+0x7c/0xb8
process_one_work+0x128/0x21c
process_scheduled_works+0x40/0x54
worker_thread+0x1ec/0x2a8
kthread+0x138/0x158
ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out.
CVE-2021-47497
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm rq: don't queue request to blk-mq during DM suspend
DM uses blk-mq's quiesce/unquiesce to stop/start device mapper queue.
But blk-mq's unquiesce may come from outside events, such as elevator
switch, updating nr_requests or others, and request may come during
suspend, so simply ask for blk-mq to requeue it.
Fixes one kernel panic issue when running updating nr_requests and
dm-mpath suspend/resume stress test.
CVE-2021-47498
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iio: mma8452: Fix trigger reference couting
The mma8452 driver directly assigns a trigger to the struct iio_dev. The
IIO core when done using this trigger will call `iio_trigger_put()` to drop
the reference count by 1.
Without the matching `iio_trigger_get()` in the driver the reference count
can reach 0 too early, the trigger gets freed while still in use and a
use-after-free occurs.
Fix this by getting a reference to the trigger before assigning it to the
IIO device.
CVE-2021-47500
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc
When trying to dump VFs VSI RX/TX descriptors
using debugfs there was a crash
due to NULL pointer dereference in i40e_dbg_dump_desc.
Added a check to i40e_dbg_dump_desc that checks if
VSI type is correct for dumping RX/TX descriptors.
CVE-2021-47501
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix use-after-free due to delegation race
A delegation break could arrive as soon as we've called vfs_setlease. A
delegation break runs a callback which immediately (in
nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we
then exit nfs4_set_delegation without hashing the delegation, it will be
freed as soon as the callback is done with it, without ever being
removed from del_recall_lru.
Symptoms show up later as use-after-free or list corruption warnings,
usually in the laundromat thread.
I suspect aba2072f4523 "nfsd: grant read delegations to clients holding
writes" made this bug easier to hit, but I looked as far back as v3.0
and it looks to me it already had the same problem. So I'm not sure
where the bug was introduced; it may have been there from the beginning.
CVE-2021-47506
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Limit the period size to 16MB
Set the practical limit to the period size (the fragment shift in OSS)
instead of a full 31bit; a too large value could lead to the exhaust
of memory as we allocate temporary buffers of the period size, too.
As of this patch, we set to 16MB limit, which should cover all use
cases.
CVE-2021-47509
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Fix negative period/buffer sizes
The period size calculation in OSS layer may receive a negative value
as an error, but the code there assumes only the positive values and
handle them with size_t. Due to that, a too big value may be passed
to the lower layers.
This patch changes the code to handle with ssize_t and adds the proper
error checks appropriately.
CVE-2021-47511
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nfp: Fix memory leak in nfp_cpp_area_cache_add()
In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a
CPP area structure. But in line 807 (#2), when the cache is allocated
failed, this CPP area structure is not freed, which will result in
memory leak.
We can fix it by freeing the CPP area when the cache is allocated
failed (#2).
792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)
793 {
794 struct nfp_cpp_area_cache *cache;
795 struct nfp_cpp_area *area;
800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),
801 0, size);
// #1: allocates and initializes
802 if (!area)
803 return -ENOMEM;
805 cache = kzalloc(sizeof(*cache), GFP_KERNEL);
806 if (!cache)
807 return -ENOMEM; // #2: missing free
817 return 0;
818 }
CVE-2021-47516
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done
The done() netlink callback nfc_genl_dump_ses_done() should check if
received argument is non-NULL, because its allocation could fail earlier
in dumpit() (nfc_genl_dump_ses()).
CVE-2021-47518
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: pch_can: pch_can_rx_normal: fix use after free
After calling netif_receive_skb(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is dereferenced
just after the call netif_receive_skb(skb).
Reordering the lines solves the issue.
CVE-2021-47520
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr
This buffer is currently allocated in hfi1_init():
if (reinit)
ret = init_after_reset(dd);
else
ret = loadtime_init(dd);
if (ret)
goto done;
/* allocate dummy tail memory for all receive contexts */
dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev,
sizeof(u64),
&dd->rcvhdrtail_dummy_dma,
GFP_KERNEL);
if (!dd->rcvhdrtail_dummy_kvaddr) {
dd_dev_err(dd, "cannot allocate dummy tail memory\n");
ret = -ENOMEM;
goto done;
}
The reinit triggered path will overwrite the old allocation and leak it.
Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation
to hfi1_free_devdata().
CVE-2021-47523
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: core: fix transmit-buffer reset and memleak
Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use
tty_port_close") converted serial core to use tty_port_close() but
failed to notice that the transmit buffer still needs to be freed on
final close.
Not freeing the transmit buffer means that the buffer is no longer
cleared on next open so that any ioctl() waiting for the buffer to drain
might wait indefinitely (e.g. on termios changes) or that stale data can
end up being transmitted in case tx is restarted.
Furthermore, the buffer of any port that has been opened would leak on
driver unbind.
Note that the port lock is held when clearing the buffer pointer due to
the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race
between uart_put_char() and uart_shutdown()").
Also note that the tty-port shutdown() callback is not called for
console ports so it is not strictly necessary to free the buffer page
after releasing the lock (cf. d72402145ace ("tty/serial: do not free
trasnmit buffer page under port lock")).
CVE-2021-47527
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()
In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and
tmp->tx_cq will be freed on the error path of mlx4_en_copy_priv().
After that mlx4_en_alloc_resources() is called and there is a dereference
of &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to
a use after free problem on failure of mlx4_en_copy_priv().
Fix this bug by adding a check of mlx4_en_copy_priv()
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_MLX4_EN=m show no new warnings,
and our static analyzer no longer warns about this code.
CVE-2021-47541
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()
In qlcnic_83xx_add_rings(), the indirect function of
ahw->hw_ops->alloc_mbx_args will be called to allocate memory for
cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),
which could lead to a NULL pointer dereference on failure of the
indirect function like qlcnic_83xx_alloc_mbx_args().
Fix this bug by adding a check of alloc_mbx_args(), this patch
imitates the logic of mbx_cmd()'s failure handling.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_QLCNIC=m show no new warnings, and our
static analyzer no longer warns about this code.
CVE-2021-47542
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix page frag corruption on page fault
Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.
The root cause is quite similar to the one addressed by
commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from
memory reclaim"). Here the nested access to the task page frag
is caused by a page fault on the (mmapped) user-space memory
buffer coming from the cifs file.
The page fault handler performs an smb transaction on a different
socket, inside the same process context. Since sk->sk_allaction
for such socket does not prevent the usage for the task_frag,
the nested allocation modify "under the hood" the page frag
in use by the outer sendmsg call, corrupting the stream.
The overall relevant stack trace looks like the following:
httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked:
ffffffff91461d91 tcp_sendmsg_locked+0x1
ffffffff91462b57 tcp_sendmsg+0x27
ffffffff9139814e sock_sendmsg+0x3e
ffffffffc06dfe1d smb_send_kvec+0x28
[...]
ffffffffc06cfaf8 cifs_readpages+0x213
ffffffff90e83c4b read_pages+0x6b
ffffffff90e83f31 __do_page_cache_readahead+0x1c1
ffffffff90e79e98 filemap_fault+0x788
ffffffff90eb0458 __do_fault+0x38
ffffffff90eb5280 do_fault+0x1a0
ffffffff90eb7c84 __handle_mm_fault+0x4d4
ffffffff90eb8093 handle_mm_fault+0xc3
ffffffff90c74f6d __do_page_fault+0x1ed
ffffffff90c75277 do_page_fault+0x37
ffffffff9160111e page_fault+0x1e
ffffffff9109e7b5 copyin+0x25
ffffffff9109eb40 _copy_from_iter_full+0xe0
ffffffff91462370 tcp_sendmsg_locked+0x5e0
ffffffff91462370 tcp_sendmsg_locked+0x5e0
ffffffff91462b57 tcp_sendmsg+0x27
ffffffff9139815c sock_sendmsg+0x4c
ffffffff913981f7 sock_write_iter+0x97
ffffffff90f2cc56 do_iter_readv_writev+0x156
ffffffff90f2dff0 do_iter_write+0x80
ffffffff90f2e1c3 vfs_writev+0xa3
ffffffff90f2e27c do_writev+0x5c
ffffffff90c042bb do_syscall_64+0x5b
ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65
The cifs filesystem rightfully sets sk_allocations to GFP_NOFS,
we can avoid the nesting using the sk page frag for allocation
lacking the __GFP_FS flag. Do not define an additional mm-helper
for that, as this is strictly tied to the sk page frag usage.
v1 -> v2:
- use a stricted sk_page_frag() check instead of reordering the
code (Eric)
CVE-2021-47544
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound
In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the
'for' end, the 'k' is 8.
At this time, the array 'lp->phy[8]' may be out of bound.
CVE-2021-47547
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()
The if statement:
if (port >= DSAF_GE_NUM)
return;
limits the value of port less than DSAF_GE_NUM (i.e., 8).
However, if the value of port is 6 or 7, an array overflow could occur:
port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).
To fix this possible array overflow, we first check port and if it is
greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
CVE-2021-47548
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl
When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,
a bug is reported:
==================================================================
BUG: Unable to handle kernel data access on read at 0x80000800805b502c
Oops: Kernel access of bad area, sig: 11 [#1]
NIP [c0000000000388a4] .ioread32+0x4/0x20
LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]
Call Trace:
.free_irq+0x1c/0x4e0 (unreliable)
.ata_host_stop+0x74/0xd0 [libata]
.release_nodes+0x330/0x3f0
.device_release_driver_internal+0x178/0x2c0
.driver_detach+0x64/0xd0
.bus_remove_driver+0x70/0xf0
.driver_unregister+0x38/0x80
.platform_driver_unregister+0x14/0x30
.fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]
.__se_sys_delete_module+0x1ec/0x2d0
.system_call_exception+0xfc/0x1f0
system_call_common+0xf8/0x200
==================================================================
The triggering of the BUG is shown in the following stack:
driver_detach
device_release_driver_internal
__device_release_driver
drv->remove(dev) --> platform_drv_remove/platform_remove
drv->remove(dev) --> sata_fsl_remove
iounmap(host_priv->hcr_base); <---- unmap
kfree(host_priv); <---- free
devres_release_all
release_nodes
dr->node.release(dev, dr->data) --> ata_host_stop
ap->ops->port_stop(ap) --> sata_fsl_port_stop
ioread32(hcr_base + HCONTROL) <---- UAF
host->ops->host_stop(host)
The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should
not be executed in drv->remove. These functions should be executed in
host_stop after port_stop. Therefore, we move these functions to the
new function sata_fsl_host_stop and bind the new function to host_stop.
CVE-2021-47549
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()
Coverity reports a possible NULL dereferencing problem:
in smc_vlan_by_tcpsk():
6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).
7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.
1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower);
CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)
8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.
1624 if (is_vlan_dev(ndev)) {
Remove the manual implementation and use netdev_walk_all_lower_dev() to
iterate over the lower devices. While on it remove an obsolete function
parameter comment.
CVE-2021-47559
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix kernel panic during drive powercycle test
While looping over shost's sdev list it is possible that one
of the drives is getting removed and its sas_target object is
freed but its sdev object remains intact.
Consequently, a kernel panic can occur while the driver is trying to access
the sas_address field of sas_target object without also checking the
sas_target object for NULL.
CVE-2021-47565
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
proc/vmcore: fix clearing user buffer by properly using clear_user()
To clear a user buffer we cannot simply use memset, we have to use
clear_user(). With a virtio-mem device that registers a vmcore_cb and
has some logically unplugged memory inside an added Linux memory block,
I can easily trigger a BUG by copying the vmcore via "cp":
systemd[1]: Starting Kdump Vmcore Save Service...
kdump[420]: Kdump is using the default log level(3).
kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/
kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/
kdump[465]: saving vmcore-dmesg.txt complete
kdump[467]: saving vmcore
BUG: unable to handle page fault for address: 00007f2374e01000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0003) - permissions violation
PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867
Oops: 0003 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86
Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81
RSP: 0018:ffffc9000073be08 EFLAGS: 00010212
RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000
RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008
RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50
R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000
R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8
FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0
Call Trace:
read_vmcore+0x236/0x2c0
proc_reg_read+0x55/0xa0
vfs_read+0x95/0x190
ksys_read+0x4f/0xc0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access
Prevention (SMAP)", which is used to detect wrong access from the kernel
to user buffers like this: SMAP triggers a permissions violation on
wrong access. In the x86-64 variant of clear_user(), SMAP is properly
handled via clac()+stac().
To fix, properly use clear_user() when we're dealing with a user buffer.
CVE-2021-47566
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()
The free_rtllib() function frees the "dev" pointer so there is use
after free on the next line. Re-arrange things to avoid that.
CVE-2021-47571
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()
In resp_mode_select() sanity check the block descriptor len to avoid UAF.
BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
Read of size 1 at addr ffff888026670f50 by task scsicmd/15032
CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Call Trace:
<TASK>
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257
kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306
resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483
scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537
scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521
blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640
__blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
__blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762
__blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839
blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63
sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837
sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775
sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941
sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50
entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113
CVE-2021-47576
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_debug: Fix type in min_t to avoid stack OOB
Change min_t() to use type "u32" instead of type "int" to avoid stack out
of bounds. With min_t() type "int" the values get sign extended and the
larger value gets used causing stack out of bounds.
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976
Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707
CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189
memcpy+0x23/0x60 mm/kasan/shadow.c:65
memcpy include/linux/fortify-string.h:191 [inline]
sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976
sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000
fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162
fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]
resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887
schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478
scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533
scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]
scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699
blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639
__blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
__blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761
__blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838
blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62
sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836
sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774
sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939
sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-47580
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Make do_proc_control() and do_proc_bulk() killable
The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke
usb_start_wait_urb(), which contains an uninterruptible wait with a
user-specified timeout value. If timeout value is very large and the
device being accessed does not respond in a reasonable amount of time,
the kernel will complain about "Task X blocked for more than N
seconds", as found in testing by syzbot:
INFO: task syz-executor.0:8700 blocked for more than 143 seconds.
Not tainted 5.14.0-rc7-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004
Call Trace:
context_switch kernel/sched/core.c:4681 [inline]
__schedule+0xc07/0x11f0 kernel/sched/core.c:5938
schedule+0x14b/0x210 kernel/sched/core.c:6017
schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857
do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85
__wait_for_common kernel/sched/completion.c:106 [inline]
wait_for_common kernel/sched/completion.c:117 [inline]
wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157
usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63
do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236
proc_bulk drivers/usb/core/devio.c:1273 [inline]
usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]
usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713
...
To fix this problem, this patch replaces usbfs's calls to
usb_control_msg() and usb_bulk_msg() with special-purpose code that
does essentially the same thing (as recommended in the comment for
usb_start_wait_urb()), except that it always uses a killable wait and
it uses GFP_KERNEL rather than GFP_NOIO.
CVE-2021-47582
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: systemport: Add global locking for descriptor lifecycle
The descriptor list is a shared resource across all of the transmit queues, and
the locking mechanism used today only protects concurrency across a given
transmit queue between the transmit and reclaiming. This creates an opportunity
for the SYSTEMPORT hardware to work on corrupted descriptors if we have
multiple producers at once which is the case when using multiple transmit
queues.
This was particularly noticeable when using multiple flows/transmit queues and
it showed up in interesting ways in that UDP packets would get a correct UDP
header checksum being calculated over an incorrect packet length. Similarly TCP
packets would get an equally correct checksum computed by the hardware over an
incorrect packet length.
The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges
when the driver produces a new descriptor anytime it writes to the
WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to
re-organize its descriptors and it is possible that concurrent TX queues
eventually break this internal allocation scheme to the point where the
length/status part of the descriptor gets used for an incorrect data buffer.
The fix is to impose a global serialization for all TX queues in the short
section where we are writing to the WRITE_PORT_{HI,LO} registers which solves
the corruption even with multiple concurrent TX queues being used.
CVE-2021-47587
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sit: do not call ipip6_dev_free() from sit_init_net()
ipip6_dev_free is sit dev->priv_destructor, already called
by register_netdevice() if something goes wrong.
Alternative would be to make ipip6_dev_free() robust against
multiple invocations, but other drivers do not implement this
strategy.
syzbot reported:
dst_release underflow
WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173
Modules linked in:
CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173
Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48
RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246
RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000
RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000
RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c
R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358
R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000
FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160
ipip6_dev_free net/ipv6/sit.c:1414 [inline]
sit_init_net+0x229/0x550 net/ipv6/sit.c:1936
ops_init+0x313/0x430 net/core/net_namespace.c:140
setup_net+0x35b/0x9d0 net/core/net_namespace.c:326
copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470
create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226
ksys_unshare+0x57d/0xb50 kernel/fork.c:3075
__do_sys_unshare kernel/fork.c:3146 [inline]
__se_sys_unshare kernel/fork.c:3144 [inline]
__x64_sys_unshare+0x34/0x40 kernel/fork.c:3144
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f66c882ce99
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200
RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000
</TASK>
CVE-2021-47588
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igbvf: fix double free in `igbvf_probe`
In `igbvf_probe`, if register_netdev() fails, the program will go to
label err_hw_init, and then to label err_ioremap. In free_netdev() which
is just below label err_ioremap, there is `list_for_each_entry_safe` and
`netif_napi_del` which aims to delete all entries in `dev->napi_list`.
The program has added an entry `adapter->rx_ring->napi` which is added by
`netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has
been freed below label err_hw_init. So this a UAF.
In terms of how to patch the problem, we can refer to igbvf_remove() and
delete the entry before `adapter->rx_ring`.
The KASAN logs are as follows:
[ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450
[ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366
[ 35.128360]
[ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14
[ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 35.131749] Call Trace:
[ 35.132199] dump_stack_lvl+0x59/0x7b
[ 35.132865] print_address_description+0x7c/0x3b0
[ 35.133707] ? free_netdev+0x1fd/0x450
[ 35.134378] __kasan_report+0x160/0x1c0
[ 35.135063] ? free_netdev+0x1fd/0x450
[ 35.135738] kasan_report+0x4b/0x70
[ 35.136367] free_netdev+0x1fd/0x450
[ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf]
[ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]
[ 35.138751] local_pci_probe+0x13c/0x1f0
[ 35.139461] pci_device_probe+0x37e/0x6c0
[ 35.165526]
[ 35.165806] Allocated by task 366:
[ 35.166414] ____kasan_kmalloc+0xc4/0xf0
[ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]
[ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf]
[ 35.168866] local_pci_probe+0x13c/0x1f0
[ 35.169565] pci_device_probe+0x37e/0x6c0
[ 35.179713]
[ 35.179993] Freed by task 366:
[ 35.180539] kasan_set_track+0x4c/0x80
[ 35.181211] kasan_set_free_info+0x1f/0x40
[ 35.181942] ____kasan_slab_free+0x103/0x140
[ 35.182703] kfree+0xe3/0x250
[ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf]
[ 35.184040] local_pci_probe+0x13c/0x1f0
CVE-2021-47589
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
inet_diag: fix kernel-infoleak for UDP sockets
KMSAN reported a kernel-infoleak [1], that can exploited
by unpriv users.
After analysis it turned out UDP was not initializing
r->idiag_expires. Other users of inet_sk_diag_fill()
might make the same mistake in the future, so fix this
in inet_sk_diag_fill().
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
copyout lib/iov_iter.c:156 [inline]
_copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
copy_to_iter include/linux/uio.h:155 [inline]
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
__skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]
netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974
sock_recvmsg_nosec net/socket.c:944 [inline]
sock_recvmsg net/socket.c:962 [inline]
sock_read_iter+0x5a9/0x630 net/socket.c:1035
call_read_iter include/linux/fs.h:2156 [inline]
new_sync_read fs/read_write.c:400 [inline]
vfs_read+0x1631/0x1980 fs/read_write.c:481
ksys_read+0x28c/0x520 fs/read_write.c:619
__do_sys_read fs/read_write.c:629 [inline]
__se_sys_read fs/read_write.c:627 [inline]
__x64_sys_read+0xdb/0x120 fs/read_write.c:627
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245
__netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370
netlink_dump_start include/linux/netlink.h:254 [inline]
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343
sock_diag_rcv_msg+0x24a/0x620
netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg net/socket.c:724 [inline]
sock_write_iter+0x594/0x690 net/socket.c:1057
do_iter_readv_writev+0xa7f/0xc70
do_iter_write+0x52c/0x1500 fs/read_write.c:851
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x63f/0xe30 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Bytes 68-71 of 312 are uninitialized
Memory access of size 312 starts at ffff88812ab54000
Data copied to user address 0000000020001440
CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
CVE-2021-47597
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: use latest_dev in btrfs_show_devname
The test case btrfs/238 reports the warning below:
WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]
CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
Call trace:
btrfs_show_devname+0x108/0x1b4 [btrfs]
show_mountinfo+0x234/0x2c4
m_show+0x28/0x34
seq_read_iter+0x12c/0x3c4
vfs_read+0x29c/0x2c8
ksys_read+0x80/0xec
__arm64_sys_read+0x28/0x34
invoke_syscall+0x50/0xf8
do_el0_svc+0x88/0x138
el0_svc+0x2c/0x8c
el0t_64_sync_handler+0x84/0xe4
el0t_64_sync+0x198/0x19c
Reason:
While btrfs_prepare_sprout() moves the fs_devices::devices into
fs_devices::seed_list, the btrfs_show_devname() searches for the devices
and found none, leading to the warning as in above.
Fix:
latest_dev is updated according to the changes to the device list.
That means we could use the latest_dev->name to show the device name in
/proc/self/mounts, the pointer will be always valid as it's assigned
before the device is deleted from the list in remove or replace.
The RCU protection is sufficient as the device structure is freed after
synchronization.
CVE-2021-47599
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm btree remove: fix use after free in rebalance_children()
Move dm_tm_unlock() after dm_tm_dec().
CVE-2021-47600
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
mac80211: track only QoS data frames for admission control
For admission control, obviously all of that only works for
QoS data frames, otherwise we cannot even access the QoS
field in the header.
Syzbot reported (see below) an uninitialized value here due
to a status of a non-QoS nullfunc packet, which isn't even
long enough to contain the QoS header.
Fix this to only do anything for QoS data packets.
CVE-2021-47602
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
audit: improve robustness of the audit queue handling
If the audit daemon were ever to get stuck in a stopped state the
kernel's kauditd_thread() could get blocked attempting to send audit
records to the userspace audit daemon. With the kernel thread
blocked it is possible that the audit queue could grow unbounded as
certain audit record generating events must be exempt from the queue
limits else the system enter a deadlock state.
This patch resolves this problem by lowering the kernel thread's
socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks
the kauditd_send_queue() function to better manage the various audit
queues when connection problems occur between the kernel and the
audit daemon. With this patch, the backlog may temporarily grow
beyond the defined limits when the audit daemon is stopped and the
system is under heavy audit pressure, but kauditd_thread() will
continue to make progress and drain the queues as it would for other
connection problems. For example, with the audit daemon put into a
stopped state and the system configured to audit every syscall it
was still possible to shutdown the system without a kernel panic,
deadlock, etc.; granted, the system was slow to shutdown but that is
to be expected given the extreme pressure of recording every syscall.
The timeout value of HZ/10 was chosen primarily through
experimentation and this developer's "gut feeling". There is likely
no one perfect value, but as this scenario is limited in scope (root
privileges would be needed to send SIGSTOP to the audit daemon), it
is likely not worth exposing this as a tunable at present. This can
always be done at a later date if it proves necessary.
CVE-2021-47603
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: netlink: af_netlink: Prevent empty skb by adding a check on len.
Adding a check on len parameter to avoid empty skb. This prevents a
division error in netem_enqueue function which is caused when skb->len=0
and skb->data_len=0 in the randomized corruption step as shown below.
skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);
Crash Report:
[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family
0 port 6081 - 0
[ 343.216110] netem: version 1.3
[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+
[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-2.el7 04/01/2014
[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
[ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
0000000000000000
[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
ffff88800f8eda40
[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
ffffffff94fb8445
[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
0000000000000000
[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
0000000000000020
[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)
knlGS:0000000000000000
[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
00000000000006e0
[ 343.250076] Call Trace:
[ 343.250423] <TASK>
[ 343.250713] ? memcpy+0x4d/0x60
[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem]
[ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem]
[ 343.253102] ? stack_trace_save+0x87/0xb0
[ 343.253655] ? filter_irq_stacks+0xb0/0xb0
[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem]
[ 343.254837] ? __kasan_check_write+0x14/0x20
[ 343.255418] ? _raw_spin_lock+0x88/0xd6
[ 343.255953] dev_qdisc_enqueue+0x50/0x180
[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090
[ 343.257083] ? netdev_core_pick_tx+0x300/0x300
[ 343.257690] ? check_kcov_mode+0x10/0x40
[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40
[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30
[ 343.259529] ? setup_object.isra.71+0x23/0x90
[ 343.260121] ? new_slab+0x26e/0x4b0
[ 343.260609] ? kasan_poison+0x3a/0x50
[ 343.261118] ? kasan_unpoison+0x28/0x50
[ 343.261637] ? __kasan_slab_alloc+0x71/0x90
[ 343.262214] ? memcpy+0x4d/0x60
[ 343.262674] ? write_comp_data+0x2f/0x90
[ 343.263209] ? __kasan_check_write+0x14/0x20
[ 343.263802] ? __skb_clone+0x5d6/0x840
[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.264958] dev_queue_xmit+0x1c/0x20
[ 343.265470] netlink_deliver_tap+0x652/0x9c0
[ 343.266067] netlink_unicast+0x5a0/0x7f0
[ 343.266608] ? netlink_attachskb+0x860/0x860
[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.267820] ? write_comp_data+0x2f/0x90
[ 343.268367] netlink_sendmsg+0x922/0xe80
[ 343.268899] ? netlink_unicast+0x7f0/0x7f0
[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60
[ 343.270099] ? write_comp_data+0x2f/0x90
[ 343.270644] ? netlink_unicast+0x7f0/0x7f0
[ 343.271210] sock_sendmsg+0x155/0x190
[ 343.271721] ____sys_sendmsg+0x75f/0x8f0
[ 343.272262] ? kernel_sendmsg+0x60/0x60
[ 343.272788] ? write_comp_data+0x2f/0x90
[ 343.273332] ? write_comp_data+0x2f/0x90
[ 343.273869] ___sys_sendmsg+0x10f/0x190
[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80
[ 343.274984] ? slab_post_alloc_hook+0x70/0x230
[ 343.275597] ? futex_wait_setup+0x240/0x240
[ 343.276175] ? security_file_alloc+0x3e/0x170
[ 343.276779] ? write_comp_d
---truncated---
CVE-2021-47606
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scpi: Fix string overflow in SCPI genpd driver
Without the bound checks for scpi_pd->name, it could result in the buffer
overflow when copying the SCPI device name from the corresponding device
tree node as the name string is set at maximum size of 30.
Let us fix it by using devm_kasprintf so that the string buffer is
allocated dynamically.
CVE-2021-47609
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: fix segfault in nfc_genl_dump_devices_done
When kmalloc in nfc_genl_dump_devices() fails then
nfc_genl_dump_devices_done() segfaults as below
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:klist_iter_exit+0x26/0x80
Call Trace:
<TASK>
class_dev_iter_exit+0x15/0x20
nfc_genl_dump_devices_done+0x3b/0x50
genl_lock_done+0x84/0xd0
netlink_sock_destruct+0x8f/0x270
__sk_destruct+0x64/0x3b0
sk_destruct+0xa8/0xd0
__sk_free+0x2e8/0x3d0
sk_free+0x51/0x90
netlink_sock_destruct_work+0x1c/0x20
process_one_work+0x411/0x710
worker_thread+0x6fd/0xa80
CVE-2021-47612
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: pciehp: Fix infinite loop in IRQ handler upon power fault
The Power Fault Detected bit in the Slot Status register differs from
all other hotplug events in that it is sticky: It can only be cleared
after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8:
If a power controller detects a main power fault on the hot-plug slot,
it must automatically set its internal main power fault latch [...].
The main power fault latch is cleared when software turns off power to
the hot-plug slot.
The stickiness used to cause interrupt storms and infinite loops which
were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault
interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable
software notification on empty slots").
Unfortunately in 2020 the infinite loop issue was inadvertently
reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt
race"): The hardirq handler pciehp_isr() clears the PFD bit until
pciehp's power_fault_detected flag is set. That happens in the IRQ
thread pciehp_ist(), which never learns of the event because the hardirq
handler is stuck in an infinite loop. Fix by setting the
power_fault_detected flag already in the hardirq handler.
CVE-2021-47617
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix queues reservation for XDP
When XDP was configured on a system with large number of CPUs
and X722 NIC there was a call trace with NULL pointer dereference.
i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12
i40e 0000:87:00.0: setup of MAIN VSI failed
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]
Call Trace:
? i40e_reconfig_rss_queues+0x130/0x130 [i40e]
dev_xdp_install+0x61/0xe0
dev_xdp_attach+0x18a/0x4c0
dev_change_xdp_fd+0x1e6/0x220
do_setlink+0x616/0x1030
? ahci_port_stop+0x80/0x80
? ata_qc_issue+0x107/0x1e0
? lock_timer_base+0x61/0x80
? __mod_timer+0x202/0x380
rtnl_setlink+0xe5/0x170
? bpf_lsm_binder_transaction+0x10/0x10
? security_capable+0x36/0x50
rtnetlink_rcv_msg+0x121/0x350
? rtnl_calcit.isra.0+0x100/0x100
netlink_rcv_skb+0x50/0xf0
netlink_unicast+0x1d3/0x2a0
netlink_sendmsg+0x22a/0x440
sock_sendmsg+0x5e/0x60
__sys_sendto+0xf0/0x160
? __sys_getsockname+0x7e/0xc0
? _copy_from_user+0x3c/0x80
? __sys_setsockopt+0xc8/0x1a0
__x64_sys_sendto+0x20/0x30
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f83fa7a39e0
This was caused by PF queue pile fragmentation due to
flow director VSI queue being placed right after main VSI.
Because of this main VSI was not able to resize its
queue allocation for XDP resulting in no queues allocated
for main VSI when XDP was turned on.
Fix this by always allocating last queue in PF queue pile
for a flow director VSI.
CVE-2021-47619
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111
The bug was found during fuzzing. Stacktrace locates it in
ath5k_eeprom_convert_pcal_info_5111.
When none of the curve is selected in the loop, idx can go
up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound.
pd = &chinfo[pier].pd_curves[idx];
There are many OOB writes using pd later in the code. So I
added a sanity check for idx. Checks for other loops involving
AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not
used outside the loops.
The patch is NOT tested with real device.
The following is the fuzzing report
BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
Write of size 1 at addr ffff8880174a4d60 by task modprobe/214
CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1
Call Trace:
dump_stack+0x76/0xa0
print_address_description.constprop.0+0x16/0x200
? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
__kasan_report.cold+0x37/0x7c
? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
kasan_report+0xe/0x20
ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
? apic_timer_interrupt+0xa/0x20
? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]
? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k]
ath5k_eeprom_init+0x2513/0x6290 [ath5k]
? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]
? usleep_range+0xb8/0x100
? apic_timer_interrupt+0xa/0x20
? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k]
ath5k_hw_init+0xb60/0x1970 [ath5k]
ath5k_init_ah+0x6fe/0x2530 [ath5k]
? kasprintf+0xa6/0xe0
? ath5k_stop+0x140/0x140 [ath5k]
? _dev_notice+0xf6/0xf6
? apic_timer_interrupt+0xa/0x20
ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k]
? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]
? mutex_lock+0x89/0xd0
? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]
local_pci_probe+0xd3/0x160
pci_device_probe+0x23f/0x3e0
? pci_device_remove+0x280/0x280
? pci_device_remove+0x280/0x280
really_probe+0x209/0x5d0
CVE-2021-47633
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com
On the case tmp_dcim=1, the index of buffer is miscalculated.
This generate a NULL pointer dereference later.
So let's fix the calcul and add a check to prevent this to reappear.
CVE-2021-47645
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Fix a memory leak in 'host1x_remove()'
Add a missing 'host1x_channel_list_free()' call in the remove function,
as already done in the error handling path of the probe function.
CVE-2021-47648
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe()
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
RIP: 0010:fb_destroy_modelist+0x38/0x100
...
Call Trace:
ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]
usb_probe_interface+0x1aa/0x3c0 [usbcore]
really_probe+0x167/0x460
...
ret_from_fork+0x1f/0x30
If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will
be called to destroy modelist in the error handling path. But modelist
has not been initialized yet, so it will result in null-ptr-deref.
Initialize modelist before calling fb_alloc_cmap() to fix this bug.
CVE-2021-47652
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/plane: Move range check for format_count earlier
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
drm_mode_object_unregister() leaking the modeset identifier. Move it to
the start of the function to avoid allocating those resources in the
first place.
CVE-2021-47659
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_restart: fix use after free bug
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the netif_rx_ni() in:
stats->rx_bytes += cf->len;
Reordering the lines solves the issue.
CVE-2021-47668
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: vxcan: vxcan_xmit: fix use after free bug
After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the canfd_frame cfd which aliases skb memory is accessed
after the netif_rx_ni().
CVE-2021-47669
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: peak_usb: fix use after free bugs
After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the peak_usb_netif_rx_ni().
Reordering the lines solves the issue.
CVE-2021-47670
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A stack overflow flaw was found in the Linux kernel's TIPC protocol functionality in the way a user sends a packet with malicious content where the number of domain member nodes is higher than the 64 allowed. This flaw allows a remote user to crash the system or possibly escalate their privileges if they have access to the TIPC network.
CVE-2022-0435
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
9
AV:N/AC:L/Au:S/C:C/I:C/A:C
A use-after-free vulnerability was found in rtsx_usb_ms_drv_remove in drivers/memstick/host/rtsx_usb_ms.c in memstick in the Linux kernel. In this flaw, a local attacker with a user privilege may impact system Confidentiality. This flaw affects kernel versions prior to 5.14 rc1.
CVE-2022-0487
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
2.1
AV:L/AC:L/Au:N/C:P/I:N/A:N
A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker.
CVE-2022-1016
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A use-after-free flaw was found in the Linux kernel's sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system.
CVE-2022-1048
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
6.9
AV:L/AC:M/Au:N/C:C/I:C/A:C
A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel's filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service.
CVE-2022-1184
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A use-after-free flaw was found in the Linux kernel's Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system.
CVE-2022-1679
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
7.2
AV:L/AC:L/Au:N/C:C/I:C/A:C
In lock_sock_nested of sock.c, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-174846563References: Upstream kernel
CVE-2022-20154
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
4.4
AV:L/AC:M/Au:N/C:P/I:P/A:P
Product: AndroidVersions: Android kernelAndroid ID: A-224546354References: Upstream kernel
CVE-2022-20368
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: Fix WRITE_SAME No Data Buffer crash
In newer version of the SBC specs, we have a NDOB bit that indicates there
is no data buffer that gets written out. If this bit is set using commands
like "sg_write_same --ndob" we will crash in target_core_iblock/file's
execute_write_same handlers when we go to access the se_cmd->t_data_sg
because its NULL.
This patch adds a check for the NDOB bit in the common WRITE SAME code
because we don't support it. And, it adds a check for zero SG elements in
each handler in case the initiator tries to send a normal WRITE SAME with
no data buffer.
CVE-2022-21546
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
addBinding in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.
CVE-2022-22822
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
build_model in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.
CVE-2022-22823
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
defineAttribute in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.
CVE-2022-22824
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
lookup in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.
CVE-2022-22825
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
nextScaffoldPart in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.
CVE-2022-22826
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
storeAtts in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.
CVE-2022-22827
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
The vmwgfx driver contains a local privilege escalation vulnerability that allows unprivileged users to gain access to files opened by other processes on the system through a dangling 'file' pointer.
CVE-2022-22942
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XML_GetBuffer, for configurations with a nonzero XML_CONTEXT_BYTES.
CVE-2022-23852
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
Expat (aka libexpat) before 2.4.4 has an integer overflow in the doProlog function.
CVE-2022-23990
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
5
AV:N/AC:L/Au:N/C:N/I:N/A:P
xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain validation of encoding, such as checks for whether a UTF-8 character is valid in a certain context.
CVE-2022-25235
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs.
CVE-2022-25236
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
In Expat (aka libexpat) before 2.4.5, an attacker can trigger stack exhaustion in build_model via a large nesting depth in the DTD element.
CVE-2022-25313
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
4.3
AV:N/AC:M/Au:N/C:N/I:N/A:P
In Expat (aka libexpat) before 2.4.5, there is an integer overflow in copyString.
CVE-2022-25314
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
5
AV:N/AC:L/Au:N/C:N/I:N/A:P
In Expat (aka libexpat) before 2.4.5, there is an integer overflow in storeRawNames.
CVE-2022-25315
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
7.5
AV:N/AC:L/Au:N/C:P/I:P/A:P
It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted.
CVE-2022-2586
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Non-transparent sharing of return predictor targets between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access.
CVE-2022-26373
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
There's a possible overflow in handle_image() when shim tries to load and execute crafted EFI executables; The handle_image() function takes into account the SizeOfRawData field from each section to be loaded. An attacker can leverage this to perform out-of-bound writes into memory. Arbitrary code execution is not discarded in such scenario.
CVE-2022-28737
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:shim-15.8-25.30.1
important
DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2022-2964. Reason: This candidate is a reservation duplicate of CVE-2022-2964. Notes: All CVE users should reference CVE-2022-2964 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
CVE-2022-28748
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate privileges on the system.
CVE-2022-2977
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition
CVE-2022-3303
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087.
CVE-2022-3564
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).
CVE-2022-36280
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An incorrect read request flaw was found in the Infrared Transceiver USB driver in the Linux kernel. This issue occurs when a user attaches a malicious USB device. A local user could use this flaw to starve the resources, causing denial of service or potentially crashing the system.
CVE-2022-3903
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
libexpat before 2.4.9 has a use-after-free in the doContent function in xmlparse.c.
CVE-2022-40674
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
A use-after-free flaw was found in Linux kernel before 5.19.2. This issue occurs in cmd_hdl_filter in drivers/staging/rtl8712/rtl8712_cmd.c, allowing an attacker to launch a local denial of service attack and gain escalation of privileges.
CVE-2022-4095
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A flaw was found in the Linux kernel's Layer 2 Tunneling Protocol (L2TP). A missing lock when clearing sk_user_data can lead to a race condition and NULL pointer dereference. A local user could use this flaw to potentially crash the system causing a denial of service.
CVE-2022-4129
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In libexpat through 2.4.9, there is a use-after free caused by overeager destruction of a shared DTD in XML_ExternalEntityParserCreate in out-of-memory situations.
CVE-2022-43680
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2022-43945
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system.
CVE-2022-4662
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
SQLite through 3.40.0, when relying on --safe for execution of an untrusted CLI script, does not properly implement the azProhibitedFunctions protection mechanism, and instead allows UDF functions such as WRITEFILE.
CVE-2022-46908
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libsqlite3-0-3.50.2-9.41.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sqlite3-tcl-3.50.2-9.41.1
important
A use-after-free exists in Python through 3.9 via heappushpop in heapq.
CVE-2022-48560
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
moderate
An issue was discovered in drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause a denial of service (panic) because input_set_capability mishandles the situation in which an event code falls outside of a bitmap.
CVE-2022-48619
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
close_altfile in filename.c in less before 606 omits shell_quote calls for LESSCLOSE.
CVE-2022-48624
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:less-458-7.15.1
important
In the Linux kernel, the following vulnerability has been resolved:
vt: fix memory overlapping when deleting chars in the buffer
A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.
Fix this problem by using replacing the scr_memcpyw with scr_memmovew.
CVE-2022-48627
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0
When walking through an inode extents, the ext4_ext_binsearch_idx() function
assumes that the extent header has been previously validated. However, there
are no checks that verify that the number of entries (eh->eh_entries) is
non-zero when depth is > 0. And this will lead to problems because the
EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:
[ 135.245946] ------------[ cut here ]------------
[ 135.247579] kernel BUG at fs/ext4/extents.c:2258!
[ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP
[ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4
[ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0
[ 135.256475] Code:
[ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246
[ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023
[ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c
[ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c
[ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024
[ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000
[ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0
[ 135.277952] Call Trace:
[ 135.278635] <TASK>
[ 135.279247] ? preempt_count_add+0x6d/0xa0
[ 135.280358] ? percpu_counter_add_batch+0x55/0xb0
[ 135.281612] ? _raw_read_unlock+0x18/0x30
[ 135.282704] ext4_map_blocks+0x294/0x5a0
[ 135.283745] ? xa_load+0x6f/0xa0
[ 135.284562] ext4_mpage_readpages+0x3d6/0x770
[ 135.285646] read_pages+0x67/0x1d0
[ 135.286492] ? folio_add_lru+0x51/0x80
[ 135.287441] page_cache_ra_unbounded+0x124/0x170
[ 135.288510] filemap_get_pages+0x23d/0x5a0
[ 135.289457] ? path_openat+0xa72/0xdd0
[ 135.290332] filemap_read+0xbf/0x300
[ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40
[ 135.292192] new_sync_read+0x103/0x170
[ 135.293014] vfs_read+0x15d/0x180
[ 135.293745] ksys_read+0xa1/0xe0
[ 135.294461] do_syscall_64+0x3c/0x80
[ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0
This patch simply adds an extra check in __ext4_ext_check(), verifying that
eh_entries is not 0 when eh_depth is > 0.
CVE-2022-48631
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup
Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup
pointer being NULL.
The pavgroup pointer is checked on the entrance of the function but
without the lcu->lock being held. Therefore there is a race window
between dasd_alias_get_start_dev() and _lcu_update() which sets
pavgroup to NULL with the lcu->lock held.
Fix by checking the pavgroup pointer with lcu->lock held.
CVE-2022-48636
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()
Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG")
made the __qlt_24xx_handle_abts() function return early if
tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean
up the allocated memory for the management command.
CVE-2022-48650
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header
If an AF_PACKET socket is used to send packets through ipvlan and the
default xmit function of the AF_PACKET socket is changed from
dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option
name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and
remains as the initial value of 65535, this may trigger slab-out-of-bounds
bugs as following:
=================================================================
UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6
ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33
all Trace:
print_address_description.constprop.0+0x1d/0x160
print_report.cold+0x4f/0x112
kasan_report+0xa3/0x130
ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
ipvlan_start_xmit+0x29/0xa0 [ipvlan]
__dev_direct_xmit+0x2e2/0x380
packet_direct_xmit+0x22/0x60
packet_snd+0x7c9/0xc40
sock_sendmsg+0x9a/0xa0
__sys_sendto+0x18a/0x230
__x64_sys_sendto+0x74/0x90
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The root cause is:
1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW
and skb->protocol is not specified as in packet_parse_headers()
2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit()
In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is
called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which
use "skb->head + skb->mac_header", out-of-bound access occurs.
This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2()
and reset mac header in multicast to solve this out-of-bound bug.
CVE-2022-48651
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix temporary data corruption in insert range
insert range doesn't discard the affected cached region
so can risk temporarily corrupting file data.
Also includes some minor cleanup (avoiding rereading
inode size repeatedly unnecessarily) to make it clearer.
CVE-2022-48667
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix temporary data corruption in collapse range
collapse range doesn't discard the affected cached region
so can risk temporarily corrupting the file data. This
fixes xfstest generic/031
I also decided to merge a minor cleanup to this into the same patch
(avoiding rereading inode size repeatedly unnecessarily) to make it
clearer.
CVE-2022-48668
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
of: fdt: fix off-by-one error in unflatten_dt_nodes()
Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")
forgot to fix up the depth check in the loop body in unflatten_dt_nodes()
which makes it possible to overflow the nps[] buffer...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
CVE-2022-48672
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix UAF when detecting digest errors
We should also bail from the io_work loop when we set rd_enabled to true,
so we don't attempt to read data from the socket when the TCP stream is
already out-of-sync or corrupted.
CVE-2022-48686
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix kernel crash during module removal
The driver incorrectly frees client instance and subsequent
i40e module removal leads to kernel crash.
Reproducer:
1. Do ethtool offline test followed immediately by another one
host# ethtool -t eth0 offline; ethtool -t eth0 offline
2. Remove recursively irdma module that also removes i40e module
host# modprobe -r irdma
Result:
[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110
[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2
[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01
[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1
[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030
[ 8687.768755] #PF: supervisor read access in kernel mode
[ 8687.773895] #PF: error_code(0x0000) - not-present page
[ 8687.779034] PGD 0 P4D 0
[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2
[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019
[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]
[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b
[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202
[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000
[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000
[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000
[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0
[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008
[ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000
[ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0
[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8687.905572] PKRU: 55555554
[ 8687.908286] Call Trace:
[ 8687.910737] <TASK>
[ 8687.912843] i40e_remove+0x2c0/0x330 [i40e]
[ 8687.917040] pci_device_remove+0x33/0xa0
[ 8687.920962] device_release_driver_internal+0x1aa/0x230
[ 8687.926188] driver_detach+0x44/0x90
[ 8687.929770] bus_remove_driver+0x55/0xe0
[ 8687.933693] pci_unregister_driver+0x2a/0xb0
[ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e]
Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this
failure is indicated back to i40e_client_subtask() that calls
i40e_client_del_instance() to free client instance referenced
by pf->cinst and sets this pointer to NULL. During the module
removal i40e_remove() calls i40e_lan_del_device() that dereferences
pf->cinst that is NULL -> crash.
Do not remove client instance when client open callbacks fails and
just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs
to take care about this situation (when netdev is up and client
is NOT opened) in i40e_notify_client_of_netdev_close() and
calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED
is set.
CVE-2022-48688
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix use-after-free warning
Fix the following use-after-free warning which is observed during
controller reset:
refcount_t: underflow; use-after-free.
WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
CVE-2022-48695
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a use-after-free
Fix the following use-after-free complaint triggered by blktests nvme/004:
BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350
Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460
Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
Call Trace:
show_stack+0x52/0x58
dump_stack_lvl+0x49/0x5e
print_report.cold+0x36/0x1e2
kasan_report+0xb9/0xf0
__asan_load4+0x6b/0x80
blk_mq_complete_request_remote+0xac/0x350
nvme_loop_queue_response+0x1df/0x275 [nvme_loop]
__nvmet_req_complete+0x132/0x4f0 [nvmet]
nvmet_req_complete+0x15/0x40 [nvmet]
nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]
nvme_loop_execute_work+0x20/0x30 [nvme_loop]
process_one_work+0x56e/0xa70
worker_thread+0x2d1/0x640
kthread+0x183/0x1c0
ret_from_fork+0x1f/0x30
CVE-2022-48697
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface()
There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and
the number of it's interfaces less than 4, an out-of-bounds read bug occurs
when parsing the interface descriptor for this device.
Fix this by checking the number of interfaces.
CVE-2022-48701
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
The voice allocator sometimes begins allocating from near the end of the
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough
index so that first_voice + requested_voice_count > NUM_G (64).
The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced
by calling aplay multiple times with 16 channels:
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
index 65 is out of range for type 'snd_emu10k1_voice [64]'
CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
ubsan_epilogue+0x9/0x3f
__ubsan_handle_out_of_bounds.cold+0x44/0x49
snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
? exit_to_user_mode_prepare+0x35/0x170
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x26/0x50
? do_syscall_64+0x69/0x90
? exit_to_user_mode_prepare+0x35/0x170
snd_pcm_ioctl+0x27/0x40 [snd_pcm]
__x64_sys_ioctl+0x95/0xd0
do_syscall_64+0x5c/0x90
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVE-2022-48702
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: add a force flush to delay work when radeon
Although radeon card fence and wait for gpu to finish processing current batch rings,
there is still a corner case that radeon lockup work queue may not be fully flushed,
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
> Configuration and Message requests are the only TLPs accepted by a Function in
> the D3hot state. All other received Requests must be handled as Unsupported Requests,
> and all received Completions may optionally be handled as Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address 00008800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000
t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258
t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000
s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018
s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000
s6 = fff00007ef07bd98
a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008
a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338
t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800
t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000
gp = ffffffff81d89690 sp = 00000000aa814126
Disabling lock debugging due to kernel taint
Trace:
[<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0
[<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290
[<ffffffff80977010>] process_one_work+0x280/0x550
[<ffffffff80977350>] worker_thread+0x70/0x7c0
[<ffffffff80977410>] worker_thread+0x130/0x7c0
[<ffffffff80982040>] kthread+0x200/0x210
[<ffffffff809772e0>] worker_thread+0x0/0x7c0
[<ffffffff80981f8c>] kthread+0x14c/0x210
[<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20
[<ffffffff80981e40>] kthread+0x0/0x210
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
<88210000> 4821ed21
So force lockup work queue flush to fix this problem.
CVE-2022-48704
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference
Added checking of pointer "function" in pcs_set_mux().
pinmux_generic_get_function() can return NULL and the pointer
"function" was dereferenced without checking against NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2022-48708
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix a possible null pointer dereference
In radeon_fp_native_mode(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
The failure status of drm_cvt_mode() on the other path is checked too.
CVE-2022-48710
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe
Running tests with a debug kernel shows that bnx2fc_recv_frame() is
modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot
a debug kernel and run the bnx2fc driver with the hardware enabled.
[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_
[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
[ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B
[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
[ 1391.699183] Call Trace:
[ 1391.699188] dump_stack_lvl+0x57/0x7d
[ 1391.699198] check_preemption_disabled+0xc8/0xd0
[ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
[ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180
[ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]
[ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]
[ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]
[ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]
[ 1391.699258] kthread+0x364/0x420
[ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50
[ 1391.699268] ? set_kthread_struct+0x100/0x100
[ 1391.699273] ret_from_fork+0x22/0x30
Restore the old get_cpu/put_cpu code with some modifications to reduce the
size of the critical section.
CVE-2022-48715
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: ca8210: Stop leaking skb's
Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. We then leak the skb
structure.
Free the skb structure upon error before returning.
CVE-2022-48722
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix off by one in BIOS boundary checking
Bounds checking when parsing init scripts embedded in the BIOS reject
access to the last byte. This causes driver initialization to fail on
Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working
console.
This is probably only seen on OpenFirmware machines like PowerPC Macs
because the BIOS image provided by OF is only the used parts of the ROM,
not a power-of-two blocks read from PCI directly so PCs always have
empty bytes at the end that are never accessed.
CVE-2022-48732
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free after failure to create a snapshot
At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and
then attach it to the transaction's list of pending snapshots. After that
we call btrfs_commit_transaction(), and if that returns an error we jump
to 'fail' label, where we kfree() the pending snapshot structure. This can
result in a later use-after-free of the pending snapshot:
1) We allocated the pending snapshot and added it to the transaction's
list of pending snapshots;
2) We call btrfs_commit_transaction(), and it fails either at the first
call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().
In both cases, we don't abort the transaction and we release our
transaction handle. We jump to the 'fail' label and free the pending
snapshot structure. We return with the pending snapshot still in the
transaction's list;
3) Another task commits the transaction. This time there's no error at
all, and then during the transaction commit it accesses a pointer
to the pending snapshot structure that the snapshot creation task
has already freed, resulting in a user-after-free.
This issue could actually be detected by smatch, which produced the
following warning:
fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list
So fix this by not having the snapshot creation ioctl directly add the
pending snapshot to the transaction's list. Instead add the pending
snapshot to the transaction handle, and then at btrfs_commit_transaction()
we add the snapshot to the list only when we can guarantee that any error
returned after that point will result in a transaction abort, in which
case the ioctl code can safely free the pending snapshot and no one can
access it anymore.
CVE-2022-48733
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
selinux: fix double free of cond_list on error paths
On error path from cond_read_list() and duplicate_policydb_cond_list()
the cond_list_destroy() gets called a second time in caller functions,
resulting in NULL pointer deref. Fix this by resetting the
cond_list_len to 0 in cond_list_destroy(), making subsequent calls a
noop.
Also consistently reset the cond_list pointer to NULL after freeing.
[PM: fix line lengths in the description]
CVE-2022-48740
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: amd-xgbe: Fix skb data length underflow
There will be BUG_ON() triggered in include/linux/skbuff.h leading to
intermittent kernel panic, when the skb length underflow is detected.
Fix this by dropping the packet if such length underflows are seen
because of inconsistencies in the hardware descriptors.
CVE-2022-48743
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Transitional solution for clcsock race issue
We encountered a crash in smc_setsockopt() and it is caused by
accessing smc->clcsock after clcsock was released.
BUG: kernel NULL pointer dereference, address: 0000000000000020
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E 5.16.0-rc4+ #53
RIP: 0010:smc_setsockopt+0x59/0x280 [smc]
Call Trace:
<TASK>
__sys_setsockopt+0xfc/0x190
__x64_sys_setsockopt+0x20/0x30
do_syscall_64+0x34/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f16ba83918e
</TASK>
This patch tries to fix it by holding clcsock_release_lock and
checking whether clcsock has already been released before access.
In case that a crash of the same reason happens in smc_getsockopt()
or smc_switch_to_fallback(), this patch also checkes smc->clcsock
in them too. And the caller of smc_switch_to_fallback() will identify
whether fallback succeeds according to the return value.
CVE-2022-48751
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
phylib: fix potential use-after-free
Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call
to phy_device_reset(phydev) after the put_device() call in phy_detach().
The comment before the put_device() call says that the phydev might go
away with put_device().
Fix potential use-after-free by calling phy_device_reset() before
put_device().
CVE-2022-48754
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
The function performs a check on the "phy" input parameter, however, it
is used before the check.
Initialize the "dev" variable after the sanity check to avoid a possible
NULL pointer dereference.
Addresses-Coverity-ID: 1493860 ("Null pointer dereference")
CVE-2022-48756
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
The bnx2fc_destroy() functions are removing the interface before calling
destroy_work. This results multiple WARNings from sysfs_remove_group() as
the controller rport device attributes are removed too early.
Replace the fcoe_port's destroy_work queue. It's not needed.
The problem is easily reproducible with the following steps.
Example:
$ dmesg -w &
$ systemctl enable --now fcoe
$ fipvlan -s -c ens2f1
$ fcoeadm -d ens2f1.802
[ 583.464488] host2: libfc: Link down on port (7500a1)
[ 583.472651] bnx2fc: 7500a1 - rport not created Yet!!
[ 583.490468] ------------[ cut here ]------------
[ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'
[ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80
[ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...
[ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1
[ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
[ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]
[ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80
[ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...
[ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282
[ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000
[ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0
[ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00
[ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400
[ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004
[ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000
[ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0
[ 584.454888] Call Trace:
[ 584.466108] device_del+0xb2/0x3e0
[ 584.481701] device_unregister+0x13/0x60
[ 584.501306] bsg_unregister_queue+0x5b/0x80
[ 584.522029] bsg_remove_queue+0x1c/0x40
[ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]
[ 584.573823] process_one_work+0x1e3/0x3b0
[ 584.592396] worker_thread+0x50/0x3b0
[ 584.609256] ? rescuer_thread+0x370/0x370
[ 584.628877] kthread+0x149/0x170
[ 584.643673] ? set_kthread_struct+0x40/0x40
[ 584.662909] ret_from_fork+0x22/0x30
[ 584.680002] ---[ end trace 53575ecefa942ece ]---
CVE-2022-48758
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev
struct rpmsg_ctrldev contains a struct cdev. The current code frees
the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the
cdev is a managed object, therefore its release is not predictable
and the rpmsg_ctrldev could be freed before the cdev is entirely
released, as in the backtrace below.
[ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c
[ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0
[ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v
[ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26
[ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
[ 93.730055] Workqueue: events kobject_delayed_cleanup
[ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)
[ 93.740216] pc : debug_print_object+0x13c/0x1b0
[ 93.744890] lr : debug_print_object+0x13c/0x1b0
[ 93.749555] sp : ffffffacf5bc7940
[ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000
[ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000
[ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000
[ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0
[ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0
[ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0
[ 93.785814] x17: 0000000000000000 x16: dfffffd000000000
[ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c
[ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000
[ 93.802244] x11: 0000000000000001 x10: 0000000000000000
[ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900
[ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000
[ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000
[ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001
[ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061
[ 93.835104] Call trace:
[ 93.837644] debug_print_object+0x13c/0x1b0
[ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0
[ 93.846987] debug_check_no_obj_freed+0x18/0x20
[ 93.851669] slab_free_freelist_hook+0xbc/0x1e4
[ 93.856346] kfree+0xfc/0x2f4
[ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8
[ 93.864445] device_release+0x84/0x168
[ 93.868310] kobject_cleanup+0x12c/0x298
[ 93.872356] kobject_delayed_cleanup+0x10/0x18
[ 93.876948] process_one_work+0x578/0x92c
[ 93.881086] worker_thread+0x804/0xcf8
[ 93.884963] kthread+0x2a8/0x314
[ 93.888303] ret_from_fork+0x10/0x18
The cdev_device_add/del() API was created to address this issue (see
commit '233ed09d7fda ("chardev: add helper function to register char
devs with a struct device")'), use it instead of cdev add/del().
CVE-2022-48759
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix hang in usb_kill_urb by adding memory barriers
The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return. It turns out the issue is not unlinking
the URB; that works just fine. Rather, the problem arises when the
wakeup notification that the URB has completed is not received.
The reason is memory-access ordering on SMP systems. In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:
CPU 0 CPU 1
---------------------------- ---------------------------------
usb_kill_urb(): __usb_hcd_giveback_urb():
... ...
atomic_inc(&urb->reject); atomic_dec(&urb->use_count);
... ...
wait_event(usb_kill_urb_queue,
atomic_read(&urb->use_count) == 0);
if (atomic_read(&urb->reject))
wake_up(&usb_kill_urb_queue);
Confining your attention to urb->reject and urb->use_count, you can
see that the overall pattern of accesses on CPU 0 is:
write urb->reject, then read urb->use_count;
whereas the overall pattern of accesses on CPU 1 is:
write urb->use_count, then read urb->reject.
This pattern is referred to in memory-model circles as SB (for "Store
Buffering"), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes. The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb->use_count while CPU 1 sees the old
un-incremented value of urb->reject. Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().
The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().
The problem is fixed by adding suitable memory barriers. To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs. The atomic_inc() and atomic_dec() accesses
themselves don't provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.
This patch adds the necessary memory barriers.
CVE-2022-48760
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci-plat: fix crash when suspend if remote wake enable
Crashed at i.mx8qm platform when suspend if enable remote wakeup
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
Hardware name: Freescale i.MX8QM MEK (DT)
Workqueue: events_unbound async_run_entry_fn
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8
sp : ffff80001394bbf0
x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578
x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000
x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001
x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0
x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453
x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c
x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620
Call trace:
xhci_disable_hub_port_wake.isra.62+0x60/0xf8
xhci_suspend+0x58/0x510
xhci_plat_suspend+0x50/0x78
platform_pm_suspend+0x2c/0x78
dpm_run_callback.isra.25+0x50/0xe8
__device_suspend+0x108/0x3c0
The basic flow:
1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend
3. xhci_suspend call xhci_disable_hub_port_wake, which access register,
but clock already gated by run time suspend.
This problem was hidden by power domain driver, which call run time resume before it.
But the below commit remove it and make this issue happen.
commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")
This patch call run time resume before suspend to make sure clock is on
before access register.
Testeb-by: Abel Vesa <abel.vesa@nxp.com>
CVE-2022-48761
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
Aditya reports [0] that his recent MacbookPro crashes in the firmware
when using the variable services at runtime. The culprit appears to be a
call to QueryVariableInfo(), which we did not use to call on Apple x86
machines in the past as they only upgraded from EFI v1.10 to EFI v2.40
firmware fairly recently, and QueryVariableInfo() (along with
UpdateCapsule() et al) was added in EFI v2.00.
The only runtime service introduced in EFI v2.00 that we actually use in
Linux is QueryVariableInfo(), as the capsule based ones are optional,
generally not used at runtime (all the LVFS/fwupd firmware update
infrastructure uses helper EFI programs that invoke capsule update at
boot time, not runtime), and not implemented by Apple machines in the
first place. QueryVariableInfo() is used to 'safely' set variables,
i.e., only when there is enough space. This prevents machines with buggy
firmwares from corrupting their NVRAMs when they run out of space.
Given that Apple machines have been using EFI v1.10 services only for
the longest time (the EFI v2.0 spec was released in 2006, and Linux
support for the newly introduced runtime services was added in 2011, but
the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),
let's avoid the EFI v2.0 ones on all Apple x86 machines.
[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/
CVE-2022-48769
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[ 29.612820] Call Trace:
[ 29.613030] <TASK>
[ 29.613201] dump_stack_lvl+0x56/0x6f
[ 29.613496] ? kmemdup+0x30/0x40
[ 29.613754] print_report.cold+0x494/0x6b7
[ 29.614082] ? kmemdup+0x30/0x40
[ 29.614340] kasan_report+0x8a/0x190
[ 29.614628] ? kmemdup+0x30/0x40
[ 29.614888] kasan_check_range+0x14d/0x1d0
[ 29.615213] memcpy+0x20/0x60
[ 29.615454] kmemdup+0x30/0x40
[ 29.615700] lgdt3306a_probe+0x52/0x310
[ 29.616339] i2c_device_probe+0x951/0xa90
CVE-2022-48772
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj
kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add():
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Fix memory leak by calling kobject_put().
CVE-2022-48775
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vsock: remove vsock from connected table when connect is interrupted by a signal
vsock_connect() expects that the socket could already be in the
TCP_ESTABLISHED state when the connecting task wakes up with a signal
pending. If this happens the socket will be in the connected table, and
it is not removed when the socket state is reset. In this situation it's
common for the process to retry connect(), and if the connection is
successful the socket will be added to the connected table a second
time, corrupting the list.
Prevent this by calling vsock_remove_connected() if a signal is received
while waiting for a connection. This is harmless if the socket is not in
the connected table, and if it is in the table then removing it will
prevent list corruption from a double add.
Note for backporting: this patch requires d5afa82c977e ("vsock: correct
removal of socket from the list"), which is in all current stable trees
except 4.9.y.
CVE-2022-48786
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-rdma: fix possible use-after-free in transport error_recovery work
While nvme_rdma_submit_async_event_work is checking the ctrl and queue
state before preparing the AER command and scheduling io_work, in order
to fully prevent a race where this check is not reliable the error
recovery work must flush async_event_work before continuing to destroy
the admin queue after setting the ctrl state to RESETTING such that
there is no race .submit_async_event and the error recovery handler
itself changing the ctrl state.
CVE-2022-48788
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix possible use-after-free in transport error_recovery work
While nvme_tcp_submit_async_event_work is checking the ctrl and queue
state before preparing the AER command and scheduling io_work, in order
to fully prevent a race where this check is not reliable the error
recovery work must flush async_event_work before continuing to destroy
the admin queue after setting the ctrl state to RESETTING such that
there is no race .submit_async_event and the error recovery handler
itself changing the ctrl state.
CVE-2022-48789
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix a possible use-after-free in controller reset during load
Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl
readiness for AER submission. This may lead to a use-after-free
condition that was observed with nvme-tcp.
The race condition may happen in the following scenario:
1. driver executes its reset_ctrl_work
2. -> nvme_stop_ctrl - flushes ctrl async_event_work
3. ctrl sends AEN which is received by the host, which in turn
schedules AEN handling
4. teardown admin queue (which releases the queue socket)
5. AEN processed, submits another AER, calling the driver to submit
6. driver attempts to send the cmd
==> use-after-free
In order to fix that, add ctrl state check to validate the ctrl
is actually able to accept the AER submission.
This addresses the above race in controller resets because the driver
during teardown should:
1. change ctrl state to RESETTING
2. flush async_event_work (as well as other async work elements)
So after 1,2, any other AER command will find the
ctrl state to be RESETTING and bail out without submitting the AER.
CVE-2022-48790
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix use-after-free for aborted TMF sas_task
Currently a use-after-free may occur if a TMF sas_task is aborted before we
handle the IO completion in mpi_ssp_completion(). The abort occurs due to
timeout.
When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the
sas_task is freed in pm8001_exec_internal_tmf_task().
However, if the I/O completion occurs later, the I/O completion still
thinks that the sas_task is available. Fix this by clearing the ccb->task
if the TMF times out - the I/O completion handler does nothing if this
pointer is cleared.
CVE-2022-48791
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task
Currently a use-after-free may occur if a sas_task is aborted by the upper
layer before we handle the I/O completion in mpi_ssp_completion() or
mpi_sata_completion().
In this case, the following are the two steps in handling those I/O
completions:
- Call complete() to inform the upper layer handler of completion of
the I/O.
- Release driver resources associated with the sas_task in
pm8001_ccb_task_free() call.
When complete() is called, the upper layer may free the sas_task. As such,
we should not touch the associated sas_task afterwards, but we do so in the
pm8001_ccb_task_free() call.
Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.
CVE-2022-48792
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: at86rf230: Stop leaking skb's
Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. In the Tx case we then leak
the skb structure.
Free the skb structure upon error before returning when appropriate.
As the 'is_tx = 0' cannot be moved in the complete handler because of a
possible race between the delay in switching to STATE_RX_AACK_ON and a
new interrupt, we introduce an intermediate 'was_tx' boolean just for
this purpose.
There is no Fixes tag applying here, many changes have been made on this
area and the issue kind of always existed.
CVE-2022-48794
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix list corruption in perf_cgroup_switch()
There's list corruption on cgrp_cpuctx_list. This happens on the
following path:
perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)
cpu_ctx_sched_in
ctx_sched_in
ctx_pinned_sched_in
merge_sched_in
perf_cgroup_event_disable: remove the event from the list
Use list_for_each_entry_safe() to allow removing an entry during
iteration.
CVE-2022-48799
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vt_ioctl: fix array_index_nospec in vt_setactivate
array_index_nospec ensures that an out-of-bounds value is set to zero
on the transient path. Decreasing the value by one afterwards causes
a transient integer underflow. vsa.console should be decreased first
and then sanitized with array_index_nospec.
Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh
Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU
Amsterdam.
CVE-2022-48804
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fix a memleak when uncloning an skb dst and its metadata
When uncloning an skb dst and its associated metadata, a new
dst+metadata is allocated and later replaces the old one in the skb.
This is helpful to have a non-shared dst+metadata attached to a specific
skb.
The issue is the uncloned dst+metadata is initialized with a refcount of
1, which is increased to 2 before attaching it to the skb. When
tun_dst_unclone returns, the dst+metadata is only referenced from a
single place (the skb) while its refcount is 2. Its refcount will never
drop to 0 (when the skb is consumed), leading to a memory leak.
Fix this by removing the call to dst_hold in tun_dst_unclone, as the
dst+metadata refcount is already 1.
CVE-2022-48809
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path
ip[6]mr_free_table() can only be called under RTNL lock.
RTNL: assertion failed at net/core/dev.c (10367)
WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Modules linked in:
CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee
RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4
R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000
FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509
ip6mr_free_table net/ipv6/ip6mr.c:389 [inline]
ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline]
ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline]
ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298
ops_init+0xaf/0x470 net/core/net_namespace.c:140
setup_net+0x54f/0xbb0 net/core/net_namespace.c:331
copy_net_ns+0x318/0x760 net/core/net_namespace.c:475
create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
copy_namespaces+0x391/0x450 kernel/nsproxy.c:178
copy_process+0x2e0c/0x7300 kernel/fork.c:2167
kernel_clone+0xe7/0xab0 kernel/fork.c:2555
__do_sys_clone+0xc8/0x110 kernel/fork.c:2672
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f4ab89f9059
Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.
RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059
RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000
RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300
R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000
R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000
</TASK>
CVE-2022-48810
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: don't release napi in __ibmvnic_open()
If __ibmvnic_open() encounters an error such as when setting link state,
it calls release_resources() which frees the napi structures needlessly.
Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.
disable napi and irqs) and leave the rest to the callers.
If caller of __ibmvnic_open() is ibmvnic_open(), it should release the
resources immediately. If the caller is do_reset() or do_hard_reset(),
they will release the resources on the next reset.
This fixes following crash that occurred when running the drmgr command
several times to add/remove a vnic interface:
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
[102056] ibmvnic 30000003 env3: Replenished 8 pools
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc000000000a3c840
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
...
CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
Workqueue: events_long __ibmvnic_reset [ibmvnic]
NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
...
NIP [c000000000a3c840] napi_enable+0x20/0xc0
LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
Call Trace:
[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
---[ end trace 5f8033b08fd27706 ]---
CVE-2022-48811
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Fix refcount issue when LOGO is received during TMF
Hung task call trace was seen during LOGO processing.
[ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued...
[ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0
[ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET
[ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1.
[ 974.309625] host1: rport 016900: Received LOGO request while in state Ready
[ 974.309627] host1: rport 016900: Delete port
[ 974.309642] host1: rport 016900: work event 3
[ 974.309644] host1: rport 016900: lld callback ev 3
[ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush.
[ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success...
[ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds.
[ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1
[ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080
[ 984.031212] Call Trace:
[ 984.031222] __schedule+0x2c4/0x700
[ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0
[ 984.031233] ? bit_wait_timeout+0x90/0x90
[ 984.031235] schedule+0x38/0xa0
[ 984.031238] io_schedule+0x12/0x40
[ 984.031240] bit_wait_io+0xd/0x50
[ 984.031243] __wait_on_bit+0x6c/0x80
[ 984.031248] ? free_buffer_head+0x21/0x50
[ 984.031251] out_of_line_wait_on_bit+0x91/0xb0
[ 984.031257] ? init_wait_var_entry+0x50/0x50
[ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2]
[ 984.031280] kjournald2+0xbd/0x270 [jbd2]
[ 984.031284] ? finish_wait+0x80/0x80
[ 984.031291] ? commit_timeout+0x10/0x10 [jbd2]
[ 984.031294] kthread+0x116/0x130
[ 984.031300] ? kthread_flush_work_fn+0x10/0x10
[ 984.031305] ret_from_fork+0x1f/0x40
There was a ref count issue when LOGO is received during TMF. This leads to
one of the I/Os hanging with the driver. Fix the ref count.
CVE-2022-48823
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Fix deadlock on DSI device attach error
DSI device attach to DSI host will be done with host device's lock
held.
Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.
Startup Call trace:
[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8
[ 35.043048] mutex_lock_nested+0x7c/0xc8
[ 35.043060] device_del+0x4c/0x3e8
[ 35.043075] device_unregister+0x20/0x40
[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28
[ 35.043093] device_for_each_child+0x68/0xb0
[ 35.043105] mipi_dsi_host_unregister+0x40/0x90
[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]
[ 35.043199] mipi_dsi_attach+0x30/0x48
[ 35.043209] tc358762_probe+0x128/0x164 [tc358762]
[ 35.043225] mipi_dsi_drv_probe+0x28/0x38
[ 35.043234] really_probe+0xc0/0x318
[ 35.043244] __driver_probe_device+0x80/0xe8
[ 35.043254] driver_probe_device+0xb8/0x118
[ 35.043263] __device_attach_driver+0x98/0xe8
[ 35.043273] bus_for_each_drv+0x84/0xd8
[ 35.043281] __device_attach+0xf0/0x150
[ 35.043290] device_initial_probe+0x1c/0x28
[ 35.043300] bus_probe_device+0xa4/0xb0
[ 35.043308] deferred_probe_work_func+0xa0/0xe0
[ 35.043318] process_one_work+0x254/0x700
[ 35.043330] worker_thread+0x4c/0x448
[ 35.043339] kthread+0x19c/0x1a8
[ 35.043348] ret_from_fork+0x10/0x20
Shutdown Call trace:
[ 365.565417] Call trace:
[ 365.565423] __switch_to+0x148/0x200
[ 365.565452] __schedule+0x340/0x9c8
[ 365.565467] schedule+0x48/0x110
[ 365.565479] schedule_timeout+0x3b0/0x448
[ 365.565496] wait_for_completion+0xac/0x138
[ 365.565509] __flush_work+0x218/0x4e0
[ 365.565523] flush_work+0x1c/0x28
[ 365.565536] wait_for_device_probe+0x68/0x158
[ 365.565550] device_shutdown+0x24/0x348
[ 365.565561] kernel_restart_prepare+0x40/0x50
[ 365.565578] kernel_restart+0x20/0x70
[ 365.565591] __do_sys_reboot+0x10c/0x220
[ 365.565605] __arm64_sys_reboot+0x2c/0x38
[ 365.565619] invoke_syscall+0x4c/0x110
[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120
[ 365.565648] do_el0_svc+0x2c/0x90
[ 365.565661] el0_svc+0x4c/0xf0
[ 365.565671] el0t_64_sync_handler+0x90/0xb8
[ 365.565682] el0t_64_sync+0x180/0x184
CVE-2022-48826
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix the behavior of READ near OFFSET_MAX
Dan Aloni reports:
> Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to
> the RPC read layers") on the client, a read of 0xfff is aligned up
> to server rsize of 0x1000.
>
> As a result, in a test where the server has a file of size
> 0x7fffffffffffffff, and the client tries to read from the offset
> 0x7ffffffffffff000, the read causes loff_t overflow in the server
> and it returns an NFS code of EINVAL to the client. The client as
> a result indefinitely retries the request.
The Linux NFS client does not handle NFS?ERR_INVAL, even though all
NFS specifications permit servers to return that status code for a
READ.
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
and return a short result. Set the EOF flag in the result to prevent
the client from retrying the READ request. This behavior appears to
be consistent with Solaris NFS servers.
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
must be converted to loff_t internally before use -- an implicit
type cast is not adequate for this purpose. Otherwise VFS checks
against sb->s_maxbytes do not work properly.
CVE-2022-48827
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix ia_size underflow
iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
NFSv4 both define file size as an unsigned 64-bit type. Thus there
is a range of valid file size values an NFS client can send that is
already larger than Linux can handle.
Currently decode_fattr4() dumps a full u64 value into ia_size. If
that value happens to be larger than S64_MAX, then ia_size
underflows. I'm about to fix up the NFSv3 behavior as well, so let's
catch the underflow in the common code path: nfsd_setattr().
CVE-2022-48828
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
iattr::ia_size is a loff_t, so these NFSv3 procedures must be
careful to deal with incoming client size values that are larger
than s64_max without corrupting the value.
Silently capping the value results in storing a different value
than the client passed in which is unexpected behavior, so remove
the min_t() check in decode_sattr3().
Note that RFC 1813 permits only the WRITE procedure to return
NFS3ERR_FBIG. We believe that NFSv3 reference implementations
also return NFS3ERR_FBIG when ia_size is too large.
CVE-2022-48829
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. There was a check for the number of endpoints, but not
for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with
usb_find_common_endpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Workqueue: usb_hub_wq hub_event
...
Call Trace:
<TASK>
aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830
input_open_device+0x1bb/0x320 drivers/input/input.c:629
kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
CVE-2022-48836
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix leaking sent_cmd skb
sent_cmd memory is not freed before freeing hci_dev causing it to leak
it contents.
CVE-2022-48844
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net-sysfs: add check for netdevice being present to speed_show
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
CVE-2022-48850
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
and a corresponding dxferp. The peculiar thing about this is that TUR
is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
bounces the user-space buffer. As if the device was to transfer into
it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
sg_build_indirect()") we make sure this first bounce buffer is
allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
device won't touch the buffer we prepare as if the we had a
DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
and the buffer allocated by SG is mapped by the function
virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
scatter-gather and not scsi generics). This mapping involves bouncing
via the swiotlb (we need swiotlb to do virtio in protected guest like
s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second
(that is swiotlb) bounce buffer (which most likely contains some
previous IO data), to the first bounce buffer, which contains all
zeros. Then we copy back the content of the first bounce buffer to
the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized,
ain't all zeros and fails.
One can argue that this is an swiotlb problem, because without swiotlb
we leak all zeros, and the swiotlb should be transparent in a sense that
it does not affect the outcome (if all other participants are well
behaved).
Copying the content of the original buffer into the swiotlb buffer is
the only way I can think of to make swiotlb transparent in such
scenarios. So let's do just that if in doubt, but allow the driver
to tell us that the whole mapped buffer is going to be overwritten,
in which case we can preserve the old behavior and avoid the performance
impact of the extra bounce.
CVE-2022-48853
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix kernel-infoleak for SCTP sockets
syzbot reported a kernel infoleak [1] of 4 bytes.
After analysis, it turned out r->idiag_expires is not initialized
if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()
Make sure to clear idiag_timer/idiag_retrans/idiag_expires
and let inet_diag_msg_sctpasoc_fill() fill them again if needed.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
copyout lib/iov_iter.c:154 [inline]
_copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
copy_to_iter include/linux/uio.h:162 [inline]
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
__skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]
netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977
sock_recvmsg_nosec net/socket.c:948 [inline]
sock_recvmsg net/socket.c:966 [inline]
__sys_recvfrom+0x795/0xa10 net/socket.c:2097
__do_sys_recvfrom net/socket.c:2115 [inline]
__se_sys_recvfrom net/socket.c:2111 [inline]
__x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3247 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1158 [inline]
netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248
__netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373
netlink_dump_start include/linux/netlink.h:254 [inline]
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341
sock_diag_rcv_msg+0x24a/0x620
netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343
netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:705 [inline]
sock_sendmsg net/socket.c:725 [inline]
sock_write_iter+0x594/0x690 net/socket.c:1061
do_iter_readv_writev+0xa7f/0xc70
do_iter_write+0x52c/0x1500 fs/read_write.c:851
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x645/0xe00 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Bytes 68-71 of 2508 are uninitialized
Memory access of size 2508 starts at ffff888114f9b000
Data copied to user address 00007f7fe09ff2e0
CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
CVE-2022-48855
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFC: port100: fix use-after-free in port100_send_complete
Syzbot reported UAF in port100_send_complete(). The root case is in
missing usb_kill_urb() calls on error handling path of ->probe function.
port100_send_complete() accesses devm allocated memory which will be
freed on probe failure. We should kill this urbs before returning an
error from probe function to prevent reported use-after-free
Fail log:
BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
...
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
__kasan_report mm/kasan/report.c:442 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
__usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
...
Allocated by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:436 [inline]
____kasan_kmalloc mm/kasan/common.c:515 [inline]
____kasan_kmalloc mm/kasan/common.c:474 [inline]
__kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
alloc_dr drivers/base/devres.c:116 [inline]
devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
devm_kzalloc include/linux/device.h:209 [inline]
port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502
Freed by task 1255:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
kasan_slab_free include/linux/kasan.h:236 [inline]
__cache_free mm/slab.c:3437 [inline]
kfree+0xf8/0x2b0 mm/slab.c:3794
release_nodes+0x112/0x1a0 drivers/base/devres.c:501
devres_release_all+0x114/0x190 drivers/base/devres.c:530
really_probe+0x626/0xcc0 drivers/base/dd.c:670
CVE-2022-48857
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ethernet: Fix error handling in xemaclite_of_probe
This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid the
refcount leak. As the remove function do.
CVE-2022-48860
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mISDN: Fix memory leak in dsp_pipeline_build()
dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),
but then it updates dup variable by strsep(&dup, "|").
As a result when it calls kfree(dup), the dup variable contains NULL.
Found by Linux Driver Verification project (linuxtesting.org) with SVACE.
CVE-2022-48863
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix kernel panic when enabling bearer
When enabling a bearer on a node, a kernel panic is observed:
[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
...
[ 4.520030] Call Trace:
[ 4.520689] <IRQ>
[ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc]
[ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc]
[ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc]
[ 4.525292] tipc_rcv+0x5da/0x730 [tipc]
[ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0
[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc]
[ 4.528737] __netif_receive_skb_list_core+0x20b/0x260
[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0
[ 4.531450] ? dev_gro_receive+0x4c2/0x680
[ 4.532512] napi_complete_done+0x6f/0x180
[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]
...
The node in question is receiving activate messages in another
thread after changing bearer status to allow message sending/
receiving in current thread:
thread 1 | thread 2
-------- | --------
|
tipc_enable_bearer() |
test_and_set_bit_lock() |
tipc_bearer_xmit_skb() |
| tipc_l2_rcv_msg()
| tipc_rcv()
| __tipc_node_link_up()
| tipc_link_build_state_msg()
| tipc_link_build_proto_msg()
| tipc_mon_prep()
| {
| ...
| // null-pointer dereference
| u16 gen = mon->dom_gen;
| ...
| }
// Not being executed yet |
tipc_mon_create() |
{ |
... |
// allocate |
mon = kzalloc(); |
... |
} |
Monitoring pointer in thread 2 is dereferenced before monitoring data
is allocated in thread 1. This causes kernel panic.
This commit fixes it by allocating the monitoring data before enabling
the bearer to receive messages.
CVE-2022-48865
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: sdata can be NULL during AMPDU start
ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
deauthentication is ongoing.
Here a trace triggering the race with the hostapd test
multi_ap_fronthaul_on_ap:
(gdb) list *drv_ampdu_action+0x46
0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
391 int ret = -EOPNOTSUPP;
392
393 might_sleep();
394
395 sdata = get_bss_sdata(sdata);
396 if (!check_sdata_in_driver(sdata))
397 return -EIO;
398
399 trace_drv_ampdu_action(local, sdata, params);
400
wlan0: moving STA 02:00:00:00:03:00 to state 3
wlan0: associated
wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
wlan0: moving STA 02:00:00:00:03:00 to state 2
wlan0: moving STA 02:00:00:00:03:00 to state 1
wlan0: Removed STA 02:00:00:00:03:00
wlan0: Destroyed STA 02:00:00:00:03:00
BUG: unable to handle page fault for address: fffffffffffffb48
PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Workqueue: phy3 ieee80211_ba_session_work [mac80211]
RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
Call Trace:
<TASK>
ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]
ieee80211_ba_session_work+0xff/0x2e0 [mac80211]
process_one_work+0x29f/0x620
worker_thread+0x4d/0x3d0
? process_one_work+0x620/0x620
kthread+0xfb/0x120
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
</TASK>
CVE-2022-48875
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: fix pci device refcount leak
As the comment of pci_get_domain_bus_and_slot() says, it
returns a PCI device with refcount incremented, when finish
using it, the caller must decrement the reference count by
calling pci_dev_put().
In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
pci_dev_put() is called to avoid leak.
CVE-2022-48896
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix GEM handle creation UAF
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference. For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.
CVE-2022-48899
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: free reset-work-item when flushing
Fix a tiny memory leak when flushing the reset work queue.
CVE-2022-48905
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ensure we call ipv6_mc_down() at most once
There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:
either the network device is actually going down, or IPv6 was disabled
on the interface.
If either of them stays down while the other is toggled, we repeatedly
call the code for NETDEV_DOWN, including ipv6_mc_down(), while never
calling the corresponding ipv6_mc_up() in between. This will cause a
new entry in idev->mc_tomb to be allocated for each multicast group
the interface is subscribed to, which in turn leaks one struct ifmcaddr6
per nontrivial multicast group the interface is subscribed to.
The following reproducer will leak at least $n objects:
ip addr add ff2e::4242/32 dev eth0 autojoin
sysctl -w net.ipv6.conf.eth0.disable_ipv6=1
for i in $(seq 1 $n); do
ip link set up eth0; ip link set down eth0
done
Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the
sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)
can also be used to create a nontrivial idev->mc_list, which will the
leak objects with the right up-down-sequence.
Based on both sources for NETDEV_DOWN events the interface IPv6 state
should be considered:
- not ready if the network interface is not ready OR IPv6 is disabled
for it
- ready if the network interface is ready AND IPv6 is enabled for it
The functions ipv6_mc_up() and ipv6_down() should only be run when this
state changes.
Implement this by remembering when the IPv6 state is ready, and only
run ipv6_mc_down() if it actually changed from ready to not ready.
The other direction (not ready -> ready) already works correctly, as:
- the interface notification triggered codepath for NETDEV_UP /
NETDEV_CHANGE returns early if ipv6 is disabled, and
- the disable_ipv6=0 triggered codepath skips fully initializing the
interface as long as addrconf_link_ready(dev) returns false
- calling ipv6_mc_up() repeatedly does not leak anything
CVE-2022-48910
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_queue: fix possible use-after-free
Eric Dumazet says:
The sock_hold() side seems suspect, because there is no guarantee
that sk_refcnt is not already 0.
On failure, we cannot queue the packet and need to indicate an
error. The packet will be dropped by the caller.
v2: split skb prefetch hunk into separate change
CVE-2022-48911
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix double free race when mount fails in cifs_get_root()
When cifs_get_root() fails during cifs_smb3_do_mount() we call
deactivate_locked_super() which eventually will call delayed_free() which
will free the context.
In this situation we should not proceed to enter the out: section in
cifs_smb3_do_mount() and free the same resources a second time.
[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0
[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4
[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[Thu Feb 10 12:59:06 2022] Call Trace:
[Thu Feb 10 12:59:06 2022] <IRQ>
[Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78
[Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117
[Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0
[Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0
[Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0
[Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20
[Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140
[Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10
[Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b
[Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150
[Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30
[Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0
...
[Thu Feb 10 12:59:07 2022] Freed by task 58179:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30
[Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40
[Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170
[Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20
[Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0
[Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
[Thu Feb 10 12:59:07 2022] Last potentially related work creation:
[Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0
[Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10
[Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0
[Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0
[Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2022-48919
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: get rid of warning on transaction commit when using flushoncommit
When using the flushoncommit mount option, during almost every transaction
commit we trigger a warning from __writeback_inodes_sb_nr():
$ cat fs/fs-writeback.c:
(...)
static void __writeback_inodes_sb_nr(struct super_block *sb, ...
{
(...)
WARN_ON(!rwsem_is_locked(&sb->s_umount));
(...)
}
(...)
The trace produced in dmesg looks like the following:
[947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3
[947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif
[947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186
[947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3
[947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)
[947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246
[947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000
[947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50
[947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000
[947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488
[947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460
[947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000
[947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0
[947.571072] Call Trace:
[947.572354] <TASK>
[947.573266] btrfs_commit_transaction+0x1f1/0x998
[947.576785] ? start_transaction+0x3ab/0x44e
[947.579867] ? schedule_timeout+0x8a/0xdd
[947.582716] transaction_kthread+0xe9/0x156
[947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407
[947.590104] kthread+0x131/0x139
[947.592168] ? set_kthread_struct+0x32/0x32
[947.595174] ret_from_fork+0x22/0x30
[947.597561] </TASK>
[947.598553] ---[ end trace 644721052755541c ]---
This is because we started using writeback_inodes_sb() to flush delalloc
when committing a transaction (when using -o flushoncommit), in order to
avoid deadlocks with filesystem freeze operations. This change was made
by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots
in flushoncommit"). After that change we started producing that warning,
and every now and then a user reports this since the warning happens too
often, it spams dmesg/syslog, and a user is unsure if this reflects any
problem that might compromise the filesystem's reliability.
We can not just lock the sb->s_umount semaphore before calling
writeback_inodes_sb(), because that would at least deadlock with
filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()
is called while we are holding that semaphore in write mode, and that can
trigger a transaction commit, resulting in a deadlock. It would also
trigger the same type of deadlock in the unmount path. Possibly, it could
also introduce some other locking dependencies that lockdep would report.
To fix this call try_to_writeback_inodes_sb() instead of
writeback_inodes_sb(), because that will try to read lock sb->s_umount
and then will only call writeback_inodes_sb() if it was able to lock it.
This is fine because the cases where it can't read lock sb->s_umount
are during a filesystem unmount or during a filesystem freeze - in those
cases sb->s_umount is write locked and sync_filesystem() is called, which
calls writeback_inodes_sb(). In other words, in all cases where we can't
take a read lock on sb->s_umount, writeback is already being triggered
elsewhere.
An alternative would be to call btrfs_start_delalloc_roots() with a
number of pages different from LONG_MAX, for example matching the number
of delalloc bytes we currently have, in
---truncated---
CVE-2022-48920
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ib_srp: Fix a deadlock
Remove the flush_workqueue(system_long_wq) call since flushing
system_long_wq is deadlock-prone and since that call is redundant with a
preceding cancel_work_sync()
CVE-2022-48930
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
configfs: fix a race in configfs_{,un}register_subsystem()
When configfs_register_subsystem() or configfs_unregister_subsystem()
is executing link_group() or unlink_group(),
it is possible that two processes add or delete list concurrently.
Some unfortunate interleavings of them can cause kernel panic.
One of cases is:
A --> B --> C --> D
A <-- B <-- C <-- D
delete list_head *B | delete list_head *C
--------------------------------|-----------------------------------
configfs_unregister_subsystem | configfs_unregister_subsystem
unlink_group | unlink_group
unlink_obj | unlink_obj
list_del_init | list_del_init
__list_del_entry | __list_del_entry
__list_del | __list_del
// next == C |
next->prev = prev |
| next->prev = prev
prev->next = next |
| // prev == B
| prev->next = next
Fix this by adding mutex when calling link_group() or unlink_group(),
but parent configfs_subsystem is NULL when config_item is root.
So I create a mutex configfs_subsystem_mutex.
CVE-2022-48931
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
CDC-NCM: avoid overflow in sanity checking
A broken device may give an extreme offset like 0xFFF0
and a reasonable length for a fragment. In the sanity
check as formulated now, this will create an integer
overflow, defeating the sanity check. Both offset
and offset + len need to be checked in such a manner
that no overflow can occur.
And those quantities should be unsigned.
CVE-2022-48938
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: make apf token non-zero to fix bug
In current async pagefault logic, when a page is ready, KVM relies on
kvm_arch_can_dequeue_async_page_present() to determine whether to deliver
a READY event to the Guest. This function test token value of struct
kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a
READY event is finished by Guest. If value is zero meaning that a READY
event is done, so the KVM can deliver another.
But the kvm_arch_setup_async_pf() may produce a valid token with zero
value, which is confused with previous mention and may lead the loss of
this READY event.
This bug may cause task blocked forever in Guest:
INFO: task stress:7532 blocked for more than 1254 seconds.
Not tainted 5.10.0 #16
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:stress state:D stack: 0 pid: 7532 ppid: 1409
flags:0x00000080
Call Trace:
__schedule+0x1e7/0x650
schedule+0x46/0xb0
kvm_async_pf_task_wait_schedule+0xad/0xe0
? exit_to_user_mode_prepare+0x60/0x70
__kvm_handle_async_pf+0x4f/0xb0
? asm_exc_page_fault+0x8/0x30
exc_page_fault+0x6f/0x110
? asm_exc_page_fault+0x8/0x30
asm_exc_page_fault+0x1e/0x30
RIP: 0033:0x402d00
RSP: 002b:00007ffd31912500 EFLAGS: 00010206
RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0
RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0
RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086
R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000
R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000
CVE-2022-48943
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: vivid: fix compose size exceed boundary
syzkaller found a bug:
BUG: unable to handle page fault for address: ffffc9000a3b1000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:memcpy_erms+0x6/0x10
[...]
Call Trace:
<TASK>
? tpg_fill_plane_buffer+0x856/0x15b0
vivid_fillbuff+0x8ac/0x1110
vivid_thread_vid_cap_tick+0x361/0xc90
vivid_thread_vid_cap+0x21a/0x3a0
kthread+0x143/0x180
ret_from_fork+0x1f/0x30
</TASK>
This is because we forget to check boundary after adjust compose->height
int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem
for this case.
CVE-2022-48945
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix preallocation discarding at indirect extent boundary
When preallocation extent is the first one in the extent block, the
code would corrupt extent tree header instead. Fix the problem and use
udf_delete_aext() for deleting extent to avoid some code duplication.
CVE-2022-48946
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igb: Initialize mailbox message for VF reset
When a MAC address is not assigned to the VF, that portion of the message
sent to the VF is not set. The memory, however, is allocated from the
stack meaning that information may be leaked to the VM. Initialize the
message buffer to 0 so that no information is passed to the VM in this
case.
CVE-2022-48949
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.
CVE-2022-48951
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid use-after-free in ip6_fragment()
Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.
It seems to not be always true, at least for UDP stack.
syzbot reported:
BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618
CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x15e/0x45d mm/kasan/report.c:395
kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
ip6_dst_idev include/net/ip6_fib.h:245 [inline]
ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
__ip6_finish_output net/ipv6/ip6_output.c:193 [inline]
ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206
NF_HOOK_COND include/linux/netfilter.h:291 [inline]
ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
dst_output include/net/dst.h:445 [inline]
ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161
ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966
udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286
udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313
udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606
inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xd3/0x120 net/socket.c:734
sock_write_iter+0x295/0x3d0 net/socket.c:1108
call_write_iter include/linux/fs.h:2191 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x9ed/0xdd0 fs/read_write.c:584
ksys_write+0x1ec/0x250 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fde3588c0d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9
RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a
RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000
</TASK>
Allocated by task 7618:
kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
__kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slab.h:737 [inline]
slab_alloc_node mm/slub.c:3398 [inline]
slab_alloc mm/slub.c:3406 [inline]
__kmem_cache_alloc_lru mm/slub.c:3413 [inline]
kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422
dst_alloc+0x14a/0x1f0 net/core/dst.c:92
ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344
ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]
rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]
ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254
pol_lookup_func include/net/ip6_fib.h:582 [inline]
fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121
ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625
ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638
ip6_route_output include/net/ip6_route.h:98 [inline]
ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092
ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222
ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260
udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554
inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
sock_sendmsg_nosec n
---truncated---
CVE-2022-48956
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ethernet: aeroflex: fix potential skb leak in greth_init_rings()
The greth_init_rings() function won't free the newly allocated skb when
dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.
Compile tested only.
CVE-2022-48958
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: hisilicon: Fix potential use-after-free in hix5hd2_rx()
The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.
CVE-2022-48960
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: hisilicon: Fix potential use-after-free in hisi_femac_rx()
The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.
CVE-2022-48962
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: mvneta: Prevent out of bounds read in mvneta_config_rss()
The pp->indir[0] value comes from the user. It is passed to:
if (cpu_online(pp->rxq_def))
inside the mvneta_percpu_elect() function. It needs bounds checkeding
to ensure that it is not beyond the end of the cpu bitmap.
CVE-2022-48966
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: Bounds check struct nfc_target arrays
While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:
memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18)
This appears to be a legitimate lack of bounds checking in
nci_add_new_protocol(). Add the missing checks.
CVE-2022-48967
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Fix NULL sring after live migration
A NAPI is setup for each network sring to poll data to kernel
The sring with source host is destroyed before live migration and
new sring with target host is setup after live migration.
The NAPI for the old sring is not deleted until setup new sring
with target host after migration. With busy_poll/busy_read enabled,
the NAPI can be polled before got deleted when resume VM.
BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: xennet_poll+0xae/0xd20
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Call Trace:
finish_task_switch+0x71/0x230
timerqueue_del+0x1d/0x40
hrtimer_try_to_cancel+0xb5/0x110
xennet_alloc_rx_buffers+0x2a0/0x2a0
napi_busy_loop+0xdb/0x270
sock_poll+0x87/0x90
do_sys_poll+0x26f/0x580
tracing_map_insert+0x1d4/0x2f0
event_hist_trigger+0x14a/0x260
finish_task_switch+0x71/0x230
__schedule+0x256/0x890
recalc_sigpending+0x1b/0x50
xen_sched_clock+0x15/0x20
__rb_reserve_next+0x12d/0x140
ring_buffer_lock_reserve+0x123/0x3d0
event_triggers_call+0x87/0xb0
trace_event_buffer_commit+0x1c4/0x210
xen_clocksource_get_cycles+0x15/0x20
ktime_get_ts64+0x51/0xf0
SyS_ppoll+0x160/0x1a0
SyS_ppoll+0x160/0x1a0
do_syscall_64+0x73/0x130
entry_SYSCALL_64_after_hwframe+0x41/0xa6
...
RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900
CR2: 0000000000000008
---[ end trace f8601785b354351c ]---
xen frontend should remove the NAPIs for the old srings before live
migration as the bond srings are destroyed
There is a tiny window between the srings are set to NULL and
the NAPIs are disabled, It is safe as the NAPI threads are still
frozen at that time
CVE-2022-48969
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix not cleanup led when bt_init fails
bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.
This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:
BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
Call Trace:
<TASK>
led_trigger_register+0x10d/0x4f0
led_trigger_register_simple+0x7d/0x100
bt_init+0x39/0xf7 [bluetooth]
do_one_initcall+0xd0/0x4e0
CVE-2022-48971
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()
Kernel fault injection test reports null-ptr-deref as follows:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
Call Trace:
<TASK>
raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87
call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944
unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982
unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879
register_netdevice+0x9a8/0xb90 net/core/dev.c:10083
ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659
ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229
mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316
ieee802154_if_add() allocates wpan_dev as netdev's private data, but not
init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage
the list when device register/unregister, and may lead to null-ptr-deref.
Use INIT_LIST_HEAD() on it to initialize it correctly.
CVE-2022-48972
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gpio: amd8111: Fix PCI device reference count leak
for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.
If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL
input parameter, there is no problem for the 'Device not found' branch.
For the normal path, add pci_dev_put() in amd_gpio_exit().
CVE-2022-48973
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix shift-out-of-bounds in hid_report_raw_event
Syzbot reported shift-out-of-bounds in hid_report_raw_event.
microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
snto32 drivers/hid/hid-core.c:1323 [inline]
hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
hid_process_report drivers/hid/hid-core.c:1665 [inline]
hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
__usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers+0x76a/0x980 kernel/time/timer.c:1790
run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
__do_softirq+0x277/0x75b kernel/softirq.c:571
__irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
======================================================================
If the size of the integer (unsigned n) is bigger than 32 in snto32(),
shift exponent will be too large for 32-bit type 'int', resulting in a
shift-out-of-bounds bug.
Fix this by adding a check on the size of the integer (unsigned n) in
snto32(). To add support for n greater than 32 bits, set n to 32, if n
is greater than 32.
CVE-2022-48978
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix race on per-CQ variable napi work_done
After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be
cleared, and another CPU can start napi thread and access per-CQ variable,
cq->work_done. If the other thread (for example, from busy_poll) sets
it to a value >= budget, this thread will continue to run when it should
stop, and cause memory corruption and panic.
To fix this issue, save the per-CQ work_done variable in a local variable
before napi_complete_done(), so it won't be corrupted by a possible
concurrent thread after napi_complete_done().
Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done
variable race is fixed, so the driver is able to reliably support features
like busy_poll.
CVE-2022-48985
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
memcg: fix possible use-after-free in memcg_write_event_control()
memcg_write_event_control() accesses the dentry->d_name of the specified
control fd to route the write call. As a cgroup interface file can't be
renamed, it's safe to access d_name as long as the specified file is a
regular cgroup file. Also, as these cgroup interface files can't be
removed before the directory, it's safe to access the parent too.
Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a
call to __file_cft() which verified that the specified file is a regular
cgroupfs file before further accesses. The cftype pointer returned from
__file_cft() was no longer necessary and the commit inadvertently dropped
the file type check with it allowing any file to slip through. With the
invarients broken, the d_name and parent accesses can now race against
renames and removals of arbitrary files and cause use-after-free's.
Fix the bug by resurrecting the file type check in __file_cft(). Now that
cgroupfs is implemented through kernfs, checking the file operations needs
to go through a layer of indirection. Instead, let's check the superblock
and dentry type.
CVE-2022-48988
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
Any codepath that zaps page table entries must invoke MMU notifiers to
ensure that secondary MMUs (like KVM) don't keep accessing pages which
aren't mapped anymore. Secondary MMUs don't hold their own references to
pages that are mirrored over, so failing to notify them can lead to page
use-after-free.
I'm marking this as addressing an issue introduced in commit f3f0e1d2150b
("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of
the security impact of this only came in commit 27e1f8273113 ("khugepaged:
enable collapse pmd for pte-mapped THP"), which actually omitted flushes
for the removal of present PTEs, not just for the removal of empty page
tables.
CVE-2022-48991
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ASoC: soc-pcm: Add NULL check in BE reparenting
Add NULL check in dpcm_be_reparent API, to handle
kernel NULL pointer dereference error.
The issue occurred in fuzzing test.
CVE-2022-48992
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
char: tpm: Protect tpm_pm_suspend with locks
Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.
Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:
tpm tpm0: tpm_transmit: tpm_recv: error -52
tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Call Trace:
tpm_tis_status.cold+0x19/0x20
tpm_transmit+0x13b/0x390
tpm_transmit_cmd+0x20/0x80
tpm1_pm_suspend+0xa6/0x110
tpm_pm_suspend+0x53/0x80
__pnp_bus_suspend+0x35/0xe0
__device_suspend+0x10f/0x350
Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.
[Jason: reworked commit message, added metadata]
CVE-2022-48997
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix PCI device refcount leak in has_external_pci()
for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.
If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() before 'return true' to avoid reference count leak.
CVE-2022-49000
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()
for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.
If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() for the error path to avoid reference count leak.
CVE-2022-49002
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Check for null before removing sysfs attrs
If coretemp_add_core() gets an error then pdata->core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().
[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
<cpu offline>
[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188
[91855.165103] #PF: supervisor read access in kernel mode
[91855.194506] #PF: error_code(0x0000) - not-present page
[91855.224445] PGD 0 P4D 0
[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI
...
[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80
...
[91855.796571] Call Trace:
[91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp]
[91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp]
[91855.871107] cpuhp_invoke_callback+0x105/0x4b0
[91855.893432] cpuhp_thread_fun+0x8e/0x150
...
Fix this by checking for NULL first.
CVE-2022-49010
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()
As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it after using to avoid refcount leak.
CVE-2022-49011
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix use-after-free in tun_detach()
syzbot reported use-after-free in tun_detach() [1]. This causes call
trace like below:
==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673
CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x15e/0x461 mm/kasan/report.c:395
kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942
call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
call_netdevice_notifiers net/core/dev.c:1997 [inline]
netdev_wait_allrefs_any net/core/dev.c:10237 [inline]
netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351
tun_detach drivers/net/tun.c:704 [inline]
tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467
__fput+0x27c/0xa90 fs/file_table.c:320
task_work_run+0x16f/0x270 kernel/task_work.c:179
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0xb3d/0x2a30 kernel/exit.c:820
do_group_exit+0xd4/0x2a0 kernel/exit.c:950
get_signal+0x21b1/0x2440 kernel/signal.c:2858
arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869
exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The cause of the issue is that sock_put() from __tun_detach() drops
last reference count for struct net, and then notifier_call_chain()
from netdev_state_change() accesses that struct net.
This patch fixes the issue by calling sock_put() from tun_detach()
after all necessary accesses for the struct net has done.
CVE-2022-49014
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: Fix potential use-after-free
The skb is delivered to netif_rx() which may free it, after calling this,
dereferencing skb may trigger use-after-free.
CVE-2022-49015
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net/9p: Fix a potential socket leak in p9_socket_open
Both p9_fd_create_tcp() and p9_fd_create_unix() will call
p9_socket_open(). If the creation of p9_trans_fd fails,
p9_fd_create_tcp() and p9_fd_create_unix() will return an
error directly instead of releasing the cscoket, which will
result in a socket leak.
This patch adds sock_release() to fix the leak issue.
CVE-2022-49020
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
net: phy: fix null-ptr-deref while probe() failed
I got a null-ptr-deref report as following when doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
<TASK>
klist_remove+0xf1/0x1c0
device_release_driver_internal+0x23e/0x2d0
bus_remove_device+0x1bd/0x240
device_del+0x357/0x770
phy_device_remove+0x11/0x30
mdiobus_unregister+0xa5/0x140
release_nodes+0x6a/0xa0
devres_release_all+0xf8/0x150
device_unbind_cleanup+0x19/0xd0
//probe path:
phy_device_register()
device_add()
phy_connect
phy_attach_direct() //set device driver
probe() //it's failed, driver is not bound
device_bind_driver() // probe failed, it's not called
//remove path:
phy_device_remove()
device_del()
device_release_driver_internal()
__device_release_driver() //dev->drv is not NULL
klist_remove() <- knode_driver is not added yet, cause null-ptr-deref
In phy_attach_direct(), after setting the 'dev->driver', probe() fails,
device_bind_driver() is not called, so the knode_driver->n_klist is not
set, then it causes null-ptr-deref in __device_release_driver() while
deleting device. Fix this by setting dev->driver to NULL in the error
path in phy_attach_direct().
CVE-2022-49021
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
e100: Fix possible use after free in e100_xmit_prepare
In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so
e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will
resend the skb. But the skb is already freed, which will cause UAF bug
when the upper layer resends the skb.
Remove the harmful free.
CVE-2022-49026
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix error handling in iavf_init_module()
The iavf_init_module() won't destroy workqueue when pci_register_driver()
failed. Call destroy_workqueue() when pci_register_driver() failed to
prevent the resource leak.
Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")
CVE-2022-49027
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: Fix resource leak in ixgbevf_init_module()
ixgbevf_init_module() won't destroy the workqueue created by
create_singlethread_workqueue() when pci_register_driver() failed. Add
destroy_workqueue() in fail path to prevent the resource leak.
Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")
CVE-2022-49028
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails
Smatch report warning as follows:
drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:
'&data->list' not removed from list
If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will
be freed, but data->list will not be removed from driver_data.bmc_data,
then list traversal may cause UAF.
Fix by removeing it from driver_data.bmc_data before free().
CVE-2022-49029
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
important
In the Linux kernel, the following vulnerability has been resolved:
dm integrity: fix memory corruption when tag_size is less than digest size
It is possible to set up dm-integrity in such a way that the
"tag_size" parameter is less than the actual digest size. In this
situation, a part of the digest beyond tag_size is ignored.
In this case, dm-integrity would write beyond the end of the
ic->recalc_tags array and corrupt memory. The corruption happened in
integrity_recalc->integrity_sector_checksum->crypto_shash_final.
Fix this corruption by increasing the tags array so that it has enough
padding at the end to accomodate the loop in integrity_recalc() being
able to write a full digest size for the last member of the tags
array.
CVE-2022-49044
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: dev: check return value when calling dev_set_name()
If dev_set_name() fails, the dev_name() is null, check the return
value of dev_set_name() to avoid the null-ptr-deref.
CVE-2022-49046
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: aqc111: Fix out-of-bounds accesses in RX fixup
aqc111_rx_fixup() contains several out-of-bounds accesses that can be
triggered by a malicious (or defective) USB device, in particular:
- The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds,
causing OOB reads and (on big-endian systems) OOB endianness flips.
- A packet can overlap the metadata array, causing a later OOB
endianness flip to corrupt data used by a cloned SKB that has already
been handed off into the network stack.
- A packet SKB can be constructed whose tail is far beyond its end,
causing out-of-bounds heap data to be considered part of the SKB's
data.
Found doing variant analysis. Tested it with another driver (ax88179_178a), since
I don't have a aqc111 device to test it, but the code looks very similar.
CVE-2022-49051
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcmu: Fix possible page UAF
tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not
take refcount properly and just returns page pointer. When
tcmu_try_get_data_page() returns, the returned page may have been freed by
tcmu_blocks_release().
We need to get_page() under cmdr_lock to avoid concurrent
tcmu_blocks_release().
CVE-2022-49053
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check for potential null return of kmalloc_array()
As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference.
Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.
CVE-2022-49055
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: potential buffer overflow in handling symlinks
Smatch printed a warning:
arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error:
__memcpy() 'dctx->buf' too small (16 vs u32max)
It's caused because Smatch marks 'link_len' as untrusted since it comes
from sscanf(). Add a check to ensure that 'link_len' is not larger than
the size of the 'link_str' buffer.
CVE-2022-49058
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: add flush_workqueue to prevent uaf
Our detector found a concurrent use-after-free bug when detaching an
NCI device. The main reason for this bug is the unexpected scheduling
between the used delayed mechanism (timer and workqueue).
The race can be demonstrated below:
Thread-1 Thread-2
| nci_dev_up()
| nci_open_device()
| __nci_request(nci_reset_req)
| nci_send_cmd
| queue_work(cmd_work)
nci_unregister_device() |
nci_close_device() | ...
del_timer_sync(cmd_timer)[1] |
... | Worker
nci_free_device() | nci_cmd_work()
kfree(ndev)[3] | mod_timer(cmd_timer)[2]
In short, the cleanup routine thought that the cmd_timer has already
been detached by [1] but the mod_timer can re-attach the timer [2], even
it is already released [3], resulting in UAF.
This UAF is easy to trigger, crash trace by POC is like below
[ 66.703713] ==================================================================
[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490
[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33
[ 66.703974]
[ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5
[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work
[ 66.703974] Call Trace:
[ 66.703974] <TASK>
[ 66.703974] dump_stack_lvl+0x57/0x7d
[ 66.703974] print_report.cold+0x5e/0x5db
[ 66.703974] ? enqueue_timer+0x448/0x490
[ 66.703974] kasan_report+0xbe/0x1c0
[ 66.703974] ? enqueue_timer+0x448/0x490
[ 66.703974] enqueue_timer+0x448/0x490
[ 66.703974] __mod_timer+0x5e6/0xb80
[ 66.703974] ? mark_held_locks+0x9e/0xe0
[ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0
[ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410
[ 66.703974] ? queue_work_on+0x61/0x80
[ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130
[ 66.703974] process_one_work+0x8bb/0x1510
[ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230
[ 66.703974] ? rwlock_bug.part.0+0x90/0x90
[ 66.703974] ? _raw_spin_lock_irq+0x41/0x50
[ 66.703974] worker_thread+0x575/0x1190
[ 66.703974] ? process_one_work+0x1510/0x1510
[ 66.703974] kthread+0x2a0/0x340
[ 66.703974] ? kthread_complete_and_exit+0x20/0x20
[ 66.703974] ret_from_fork+0x22/0x30
[ 66.703974] </TASK>
[ 66.703974]
[ 66.703974] Allocated by task 267:
[ 66.703974] kasan_save_stack+0x1e/0x40
[ 66.703974] __kasan_kmalloc+0x81/0xa0
[ 66.703974] nci_allocate_device+0xd3/0x390
[ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0
[ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd
[ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0
[ 66.703974] tty_ioctl+0x764/0x1310
[ 66.703974] __x64_sys_ioctl+0x122/0x190
[ 66.703974] do_syscall_64+0x3b/0x90
[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 66.703974]
[ 66.703974] Freed by task 406:
[ 66.703974] kasan_save_stack+0x1e/0x40
[ 66.703974] kasan_set_track+0x21/0x30
[ 66.703974] kasan_set_free_info+0x20/0x30
[ 66.703974] __kasan_slab_free+0x108/0x170
[ 66.703974] kfree+0xb0/0x330
[ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0
[ 66.703974] nci_uart_tty_close+0xdf/0x180
[ 66.703974] tty_ldisc_kill+0x73/0x110
[ 66.703974] tty_ldisc_hangup+0x281/0x5b0
[ 66.703974] __tty_hangup.part.0+0x431/0x890
[ 66.703974] tty_release+0x3a8/0xc80
[ 66.703974] __fput+0x1f0/0x8c0
[ 66.703974] task_work_run+0xc9/0x170
[ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0
[ 66.703974] syscall_exit_to_user_mode+0x19/0x50
[ 66.703974] do_syscall_64+0x48/0x90
[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x
---truncated---
CVE-2022-49059
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()
dev_name() was called with dev.parent as argument but without to
NULL-check it before.
Solve this by checking the pointer before the call to dev_name().
CVE-2022-49060
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix the svc_deferred_event trace class
Fix a NULL deref crash that occurs when an svc_rqst is deferred
while the sunrpc tracing subsystem is enabled. svc_revisit() sets
dr->xprt to NULL, so it can't be relied upon in the tracepoint to
provide the remote's address.
Unfortunately we can't revert the "svc_deferred_class" hunk in
commit ece200ddd54b ("sunrpc: Save remote presentation address in
svc_xprt for trace events") because there is now a specific check
of event format specifiers for unsafe dereferences. The warning
that check emits is:
event svc_defer_recv has unsafe dereference of argument 1
A "%pISpc" format specifier with a "struct sockaddr *" is indeed
flagged by this check.
Instead, take the brute-force approach used by the svcrdma_qp_error
tracepoint. Convert the dr::addr field into a presentation address
in the TP_fast_assign() arm of the trace event, and store that as
a string. This fix can be backported to -stable kernels.
In the meantime, commit c6ced22997ad ("tracing: Update print fmt
check to handle new __get_sockaddr() macro") is now in v5.18, so
this wonky fix can be replaced with __sockaddr() and friends
properly during the v5.19 merge window.
CVE-2022-49065
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
veth: Ensure eth header is in skb's linear part
After feeding a decapsulated packet to a veth device with act_mirred,
skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(),
which expects at least ETH_HLEN byte of linear data (as
__dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes
unconditionally).
Use pskb_may_pull() to ensure veth_xmit() respects this constraint.
kernel BUG at include/linux/skbuff.h:2328!
RIP: 0010:eth_type_trans+0xcf/0x140
Call Trace:
<IRQ>
__dev_forward_skb2+0xe3/0x160
veth_xmit+0x6e/0x250 [veth]
dev_hard_start_xmit+0xc7/0x200
__dev_queue_xmit+0x47f/0x520
? skb_ensure_writable+0x85/0xa0
? skb_mpls_pop+0x98/0x1c0
tcf_mirred_act+0x442/0x47e [act_mirred]
tcf_action_exec+0x86/0x140
fl_classify+0x1d8/0x1e0 [cls_flower]
? dma_pte_clear_level+0x129/0x1a0
? dma_pte_clear_level+0x129/0x1a0
? prb_fill_curr_block+0x2f/0xc0
? skb_copy_bits+0x11a/0x220
__tcf_classify+0x58/0x110
tcf_classify_ingress+0x6b/0x140
__netif_receive_skb_core.constprop.0+0x47d/0xfd0
? __iommu_dma_unmap_swiotlb+0x44/0x90
__netif_receive_skb_one_core+0x3d/0xa0
netif_receive_skb+0x116/0x170
be_process_rx+0x22f/0x330 [be2net]
be_poll+0x13c/0x370 [be2net]
__napi_poll+0x2a/0x170
net_rx_action+0x22f/0x2f0
__do_softirq+0xca/0x2a8
__irq_exit_rcu+0xc1/0xe0
common_interrupt+0x83/0xa0
CVE-2022-49066
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3: Fix GICR_CTLR.RWP polling
It turns out that our polling of RWP is totally wrong when checking
for it in the redistributors, as we test the *distributor* bit index,
whereas it is a different bit number in the RDs... Oopsie boo.
This is embarassing. Not only because it is wrong, but also because
it took *8 years* to notice the blunder...
Just fix the damn thing.
CVE-2022-49074
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix qgroup reserve overflow the qgroup limit
We use extent_changeset->bytes_changed in qgroup_reserve_data() to record
how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the
bytes_changed is set as "unsigned int", and it will overflow if we try to
fallocate a range larger than 4GiB. The result is we reserve less bytes
and eventually break the qgroup limit.
Unlike regular buffered/direct write, which we use one changeset for
each ordered extent, which can never be larger than 256M. For
fallocate, we use one changeset for the whole range, thus it no longer
respects the 256M per extent limit, and caused the problem.
The following example test script reproduces the problem:
$ cat qgroup-overflow.sh
#!/bin/bash
DEV=/dev/sdj
MNT=/mnt/sdj
mkfs.btrfs -f $DEV
mount $DEV $MNT
# Set qgroup limit to 2GiB.
btrfs quota enable $MNT
btrfs qgroup limit 2G $MNT
# Try to fallocate a 3GiB file. This should fail.
echo
echo "Try to fallocate a 3GiB file..."
fallocate -l 3G $MNT/3G.file
# Try to fallocate a 5GiB file.
echo
echo "Try to fallocate a 5GiB file..."
fallocate -l 5G $MNT/5G.file
# See we break the qgroup limit.
echo
sync
btrfs qgroup show -r $MNT
umount $MNT
When running the test:
$ ./qgroup-overflow.sh
(...)
Try to fallocate a 3GiB file...
fallocate: fallocate failed: Disk quota exceeded
Try to fallocate a 5GiB file...
qgroupid rfer excl max_rfer
-------- ---- ---- --------
0/5 5.00GiB 5.00GiB 2.00GiB
Since we have no control of how bytes_changed is used, it's better to
set it to u64.
CVE-2022-49075
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
qede: confirm skb is allocated before using
qede_build_skb() assumes build_skb() always works and goes straight
to skb_reserve(). However, build_skb() can fail under memory pressure.
This results in a kernel panic because the skb to reserve is NULL.
Add a check in case build_skb() failed to allocate and return NULL.
The NULL return is handled correctly in callers to qede_build_skb().
CVE-2022-49084
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drbd: Fix five use after free bugs in get_initial_state
In get_initial_state, it calls notify_initial_state_done(skb,..) if
cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),
the skb will be freed by nlmsg_free(skb).
Then get_initial_state will goto out and the freed skb will be used by
return value skb->len, which is a uaf bug.
What's worse, the same problem goes even further: skb can also be
freed in the notify_*_state_change -> notify_*_state calls below.
Thus 4 additional uaf bugs happened.
My patch lets the problem callee functions: notify_initial_state_done
and notify_*_state_change return an error code if errors happen.
So that the error codes could be propagated and the uaf bugs can be avoid.
v2 reports a compilation warning. This v3 fixed this warning and built
successfully in my local environment with no additional warnings.
v2: https://lore.kernel.org/patchwork/patch/1435218/
CVE-2022-49085
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix leak of nested actions
While parsing user-provided actions, openvswitch module may dynamically
allocate memory and store pointers in the internal copy of the actions.
So this memory has to be freed while destroying the actions.
Currently there are only two such actions: ct() and set(). However,
there are many actions that can hold nested lists of actions and
ovs_nla_free_flow_actions() just jumps over them leaking the memory.
For example, removal of the flow with the following actions will lead
to a leak of the memory allocated by nf_ct_tmpl_alloc():
actions:clone(ct(commit),0)
Non-freed set() action may also leak the 'dst' structure for the
tunnel info including device references.
Under certain conditions with a high rate of flow rotation that may
cause significant memory leak problem (2MB per second in reporter's
case). The problem is also hard to mitigate, because the user doesn't
have direct control over the datapath flows generated by OVS.
Fix that by iterating over all the nested actions and freeing
everything that needs to be freed recursively.
New build time assertion should protect us from this problem if new
actions will be added in the future.
Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all
attributes has to be explicitly checked. sample() and clone() actions
are mixing extra attributes into the user-provided action list. That
prevents some code generalization too.
CVE-2022-49086
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()
The error handling path of the probe releases a resource that is not freed
in the remove function. In some cases, a ioremap() must be undone.
Add the missing iounmap() call in the remove function.
CVE-2022-49095
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Fix potential crash on module unload
The vmbus driver relies on the panic notifier infrastructure to perform
some operations when a panic event is detected. Since vmbus can be built
as module, it is required that the driver handles both registering and
unregistering such panic notifier callback.
After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
though, the panic notifier registration is done unconditionally in the module
initialization routine whereas the unregistering procedure is conditionally
guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability
is set.
This patch fixes that by unconditionally unregistering the panic notifier
in the module's exit routine as well.
CVE-2022-49098
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
virtio_console: eliminate anonymous module_init & module_exit
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
ffffffff832fc78c t init
ffffffff832fc79e t init
ffffffff832fc8f8 t init
Example 2: (initcall_debug log)
calling init+0x0/0x12 @ 1
initcall init+0x0/0x12 returned 0 after 15 usecs
calling init+0x0/0x60 @ 1
initcall init+0x0/0x60 returned 0 after 2 usecs
calling init+0x0/0x9a @ 1
initcall init+0x0/0x9a returned 0 after 74 usecs
CVE-2022-49100
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix memory leak in ceph_readdir when note_last_dentry returns error
Reset the last_readdir at the same time, and add a comment explaining
why we don't free last_readdir when dir_emit returns false.
CVE-2022-49107
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix inode reference leakage in ceph_get_snapdir()
The ceph_get_inode() will search for or insert a new inode into the
hash for the given vino, and return a reference to it. If new is
non-NULL, its reference is consumed.
We should release the reference when in error handing cases.
CVE-2022-49109
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use after free in hci_send_acl
This fixes the following trace caused by receiving
HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without
first checking if conn->type is in fact AMP_LINK and in case it is
do properly cleanup upper layers with hci_disconn_cfm:
==================================================================
BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50
Read of size 8 at addr ffff88800e404818 by task bluetoothd/142
CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x45/0x59
print_address_description.constprop.0+0x1f/0x150
kasan_report.cold+0x7f/0x11b
hci_send_acl+0xaba/0xc50
l2cap_do_send+0x23f/0x3d0
l2cap_chan_send+0xc06/0x2cc0
l2cap_sock_sendmsg+0x201/0x2b0
sock_sendmsg+0xdc/0x110
sock_write_iter+0x20f/0x370
do_iter_readv_writev+0x343/0x690
do_iter_write+0x132/0x640
vfs_writev+0x198/0x570
do_writev+0x202/0x280
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3
0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015
RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77
R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580
RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001
</TASK>
R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0
Allocated by task 45:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
hci_chan_create+0x9a/0x2f0
l2cap_conn_add.part.0+0x1a/0xdc0
l2cap_connect_cfm+0x236/0x1000
le_conn_complete_evt+0x15a7/0x1db0
hci_le_conn_complete_evt+0x226/0x2c0
hci_le_meta_evt+0x247/0x450
hci_event_packet+0x61b/0xe90
hci_rx_work+0x4d5/0xc50
process_one_work+0x8fb/0x15a0
worker_thread+0x576/0x1240
kthread+0x29d/0x340
ret_from_fork+0x1f/0x30
Freed by task 45:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0xfb/0x130
kfree+0xac/0x350
hci_conn_cleanup+0x101/0x6a0
hci_conn_del+0x27e/0x6c0
hci_disconn_phylink_complete_evt+0xe0/0x120
hci_event_packet+0x812/0xe90
hci_rx_work+0x4d5/0xc50
process_one_work+0x8fb/0x15a0
worker_thread+0x576/0x1240
kthread+0x29d/0x340
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88800c0f0500
The buggy address is located 24 bytes inside of
which belongs to the cache kmalloc-128 of size 128
The buggy address belongs to the page:
128-byte region [ffff88800c0f0500, ffff88800c0f0580)
flags: 0x100000000000200(slab|node=0|zone=1)
page:00000000fe45cd86 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0xc0f0
raw: 0000000000000000 0000000080100010 00000001ffffffff
0000000000000000
raw: 0100000000000200 ffffea00003a2c80 dead000000000004
ffff8880078418c0
page dumped because: kasan: bad access detected
ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
Memory state around the buggy address:
>ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
---truncated---
CVE-2022-49111
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix use after free in fc_exch_abts_resp()
fc_exch_release(ep) will decrease the ep's reference count. When the
reference count reaches zero, it is freed. But ep is still used in the
following code, which will lead to a use after free.
Return after the fc_exch_release() call to avoid use after free.
CVE-2022-49114
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Free irq vectors in order for v3 HW
If the driver probe fails to request the channel IRQ or fatal IRQ, the
driver will free the IRQ vectors before freeing the IRQs in free_irq(),
and this will cause a kernel BUG like this:
------------[ cut here ]------------
kernel BUG at drivers/pci/msi.c:369!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Call trace:
free_msi_irqs+0x118/0x13c
pci_disable_msi+0xfc/0x120
pci_free_irq_vectors+0x24/0x3c
hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw]
local_pci_probe+0x44/0xb0
work_for_cpu_fn+0x20/0x34
process_one_work+0x1d0/0x340
worker_thread+0x2e0/0x460
kthread+0x180/0x190
ret_from_fork+0x10/0x20
---[ end trace b88990335b610c11 ]---
So we use devm_add_action() to control the order in which we free the
vectors.
CVE-2022-49118
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req()
In pm8001_chip_fw_flash_update_build(), if
pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex
allocated must be freed.
CVE-2022-49119
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix task leak in pm8001_send_abort_all()
In pm8001_send_abort_all(), make sure to free the allocated sas task
if pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail.
CVE-2022-49120
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix tag leaks on error
In pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),
pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing calls
to pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()
fails.
Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abort
method fails, the tag allocated for the abort request task must be
freed. Add the missing call to pm8001_tag_free().
CVE-2022-49121
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm ioctl: prevent potential spectre v1 gadget
It appears like cmd could be a Spectre v1 gadget as it's supplied by a
user and used as an array index. Prevent the contents of kernel memory
from being leaked to userspace via speculative execution by using
array_index_nospec.
CVE-2022-49122
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj
This issue takes place in an error path in
amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into
default case, the function simply returns -EINVAL, forgetting to
decrement the reference count of a dma_fence obj, which is bumped
earlier by amdgpu_cs_get_fence(). This may result in reference count
leaks.
Fix it by decreasing the refcount of specific object before returning
the error code.
CVE-2022-49137
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: Ignore multiple conn complete events
When one of the three connection complete events is received multiple
times for the same handle, the device is registered multiple times which
leads to memory corruptions. Therefore, consequent events for a single
connection are ignored.
The conn->state can hold different values, therefore HCI_CONN_HANDLE_UNSET
is introduced to identify new connections. To make sure the events do not
contain this or another invalid handle HCI_CONN_HANDLE_MAX and checks
are introduced.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497
CVE-2022-49138
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt
This event is just specified for SCO and eSCO link types.
On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR
of an existing LE connection, LE link type and a status that triggers the
second case of the packet processing a NULL pointer dereference happens,
as conn->link is NULL.
CVE-2022-49139
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Avoid out of bounds access when parsing _CPC data
If the NumEntries field in the _CPC return package is less than 2, do
not attempt to access the "Revision" element of that package, because
it may not be present then.
BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/
CVE-2022-49145
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: fix panic on out-of-bounds guest IRQ
As guest_irq is coming from KVM_IRQFD API call, it may trigger
crash in svm_update_pi_irte() due to out-of-bounds:
crash> bt
PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8"
#0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397
#1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d
#2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d
#3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d
#4 [ffffb1ba6707fb90] no_context at ffffffff856692c9
#5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51
#6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace
[exception RIP: svm_update_pi_irte+227]
RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086
RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001
RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8
RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200
R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001
R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm]
#8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm]
#9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm]
RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b
RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020
RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0
R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0
R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0
ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b
Vmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on
out-of-bounds guest IRQ), so we can just copy source from that to fix
this.
CVE-2022-49154
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()
[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020
[ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1
[ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018
[ 12.356356] Call Trace:
[ 12.358821] dump_stack_lvl+0x34/0x44
[ 12.362514] check_preemption_disabled+0xd9/0xe0
[ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]
[ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40
[ 12.384284] local_pci_probe+0x42/0x80
[ 12.390162] ? pci_match_device+0xd7/0x110
[ 12.396366] pci_device_probe+0xfd/0x1b0
[ 12.402372] really_probe+0x1e7/0x3e0
[ 12.408114] __driver_probe_device+0xfe/0x180
[ 12.414544] driver_probe_device+0x1e/0x90
[ 12.420685] __driver_attach+0xc0/0x1c0
[ 12.426536] ? __device_attach_driver+0xe0/0xe0
[ 12.433061] ? __device_attach_driver+0xe0/0xe0
[ 12.439538] bus_for_each_dev+0x78/0xc0
[ 12.445294] bus_add_driver+0x12b/0x1e0
[ 12.451021] driver_register+0x8f/0xe0
[ 12.456631] ? 0xffffffffc07bc000
[ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx]
[ 12.468776] do_one_initcall+0x44/0x200
[ 12.474401] ? load_module+0xad3/0xba0
[ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410
[ 12.486268] do_init_module+0x5c/0x280
[ 12.491730] __do_sys_init_module+0x12e/0x1b0
[ 12.497785] do_syscall_64+0x3b/0x90
[ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 12.509764] RIP: 0033:0x7f554f73ab2e
CVE-2022-49155
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix scheduling while atomic
The driver makes a call into midlayer (fc_remote_port_delete) which can put
the thread to sleep. The thread that originates the call is in interrupt
context. The combination of the two trigger a crash. Schedule the call in
non-interrupt context where it is more safe.
kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000
kernel: Call Trace:
kernel: <IRQ>
kernel: dump_stack+0x66/0x81
kernel: __schedule_bug.cold.90+0x5/0x1d
kernel: __schedule+0x7af/0x960
kernel: schedule+0x28/0x80
kernel: schedule_timeout+0x26d/0x3b0
kernel: wait_for_completion+0xb4/0x140
kernel: ? wake_up_q+0x70/0x70
kernel: __wait_rcu_gp+0x12c/0x160
kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]
kernel: synchronize_sched+0x6c/0x80
kernel: ? call_rcu_bh+0x20/0x20
kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10
kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod]
kernel: starget_for_each_device+0x85/0xb0 [scsi_mod]
kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod]
kernel: scsi_init_io+0x388/0x3d0 [scsi_mod]
kernel: device_for_each_child+0x54/0x90
kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]
kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]
kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]
kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]
kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]
kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]
kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx]
kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]
kernel: __handle_irq_event_percpu+0x40/0x180
kernel: handle_irq_event_percpu+0x30/0x80
kernel: handle_irq_event+0x36/0x60
CVE-2022-49156
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix premature hw access after PCI error
After a recoverable PCI error has been detected and recovered, qla driver
needs to check to see if the error condition still persist and/or wait
for the OS to give the resume signal.
Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440
qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx]
Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60
[qla2xxx]
Sep 8 22:26:03 localhost kernel: Call Trace:
Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx]
Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160
[qla2xxx]
Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx]
Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120
[qla2xxx]
Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80
Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80
Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90
Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0
Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240
Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0
Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360
..
Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI
disconnect.
Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22:
qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h
Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to
capture FW dump
Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0,
waited 5221 msecs
Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio
enabled returning.
Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX
Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5
mb[0-3]=[0xffff 0xffff 0xffff 0xffff]
CVE-2022-49157
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix warning message due to adisc being flushed
Fix warning message due to adisc being flushed. Linux kernel triggered a
warning message where a different error code type is not matching up with
the expected type. Add additional translation of one error code type to
another.
WARNING: CPU: 2 PID: 1131623 at drivers/scsi/qla2xxx/qla_init.c:498
qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]
CPU: 2 PID: 1131623 Comm: drmgr Not tainted 5.13.0-rc1-autotest #1
..
GPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000
NIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]
LR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx]
Call Trace:
[c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (unreliable)
[c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx]
[c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx]
[c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx]
[c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx]
[c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120
[c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0
[c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100
[c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40
[c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130
[c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [
c00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180
[c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60
[c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20]
[c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290
[c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0
[c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330
[c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130
[c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0
[c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278
CVE-2022-49158
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Implement ref count for SRB
The timeout handler and the done function are racing. When
qla2x00_async_iocb_timeout() starts to run it can be preempted by the
normal response path (via the firmware?). qla24xx_async_gpsc_sp_done()
releases the SRB unconditionally. When scheduling back to
qla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed
sp->qpair pointer:
qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21.
qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21
qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400.
qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5
BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx]
Obvious solution to this is to introduce a reference counter. One reference
is taken for the normal code path (the 'good' case) and one for the timeout
path. As we always race between the normal good case and the timeout/abort
handler we need to serialize it. Also we cannot assume any order between
the handlers. Since this is slow path we can use proper synchronization via
locks.
When we are able to cancel a timer (del_timer returns 1) we know there
can't be any error handling in progress because the timeout handler hasn't
expired yet, thus we can safely decrement the refcounter by one.
If we are not able to cancel the timer, we know an abort handler is
running. We have to make sure we call sp->done() in the abort handlers
before calling kref_put().
CVE-2022-49159
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix crash during module load unload test
During purex packet handling the driver was incorrectly freeing a
pre-allocated structure. Fix this by skipping that entry.
System crashed with the following stack during a module unload test.
Call Trace:
sbitmap_init_node+0x7f/0x1e0
sbitmap_queue_init_node+0x24/0x150
blk_mq_init_bitmaps+0x3d/0xa0
blk_mq_init_tags+0x68/0x90
blk_mq_alloc_map_and_rqs+0x44/0x120
blk_mq_alloc_set_map_and_rqs+0x63/0x150
blk_mq_alloc_tag_set+0x11b/0x230
scsi_add_host_with_dma.cold+0x3f/0x245
qla2x00_probe_one+0xd5a/0x1b80 [qla2xxx]
Call Trace with slub_debug and debug kernel:
kasan_report_invalid_free+0x50/0x80
__kasan_slab_free+0x137/0x150
slab_free_freelist_hook+0xc6/0x190
kfree+0xe8/0x2e0
qla2x00_free_device+0x3bb/0x5d0 [qla2xxx]
qla2x00_remove_one+0x668/0xcf0 [qla2xxx]
CVE-2022-49160
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/tm: Fix more userspace r13 corruption
Commit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes a
problem in treclaim where a SLB miss can occur on the
thread_struct->ckpt_regs while SCRATCH0 is live with the saved user r13
value, clobbering it with the kernel r13 and ultimately resulting in
kernel r13 being stored in ckpt_regs.
There is an equivalent problem in trechkpt where the user r13 value is
loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss
could occur on ckpt_regs accesses after that, which will result in r13
being clobbered with a kernel value and that will get recheckpointed and
then restored to user registers.
The same memory page is accessed right before this critical window where
a SLB miss could cause corruption, so hitting the bug requires the SLB
entry be removed within a small window of instructions, which is
possible if a SLB related MCE hits there. PAPR also permits the
hypervisor to discard this SLB entry (because slb_shadow->persistent is
only set to SLB_NUM_BOLTED) although it's not known whether any
implementations would do this (KVM does not). So this is an extremely
unlikely bug, only found by inspection.
Fix this by also storing user r13 in a temporary location on the kernel
stack and don't change the r13 register from kernel r13 until the RI=0
critical section that does not fault.
The SCRATCH0 change is not strictly part of the fix, it's only used in
the RI=0 section so it does not have the same problem as the previous
SCRATCH0 bug.
CVE-2022-49164
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not clean up repair bio if submit fails
The submit helper will always run bio_endio() on the bio if it fails to
submit, so cleaning up the bio just leads to a variety of use-after-free
and NULL pointer dereference bugs because we race with the endio
function that is cleaning up the bio. Instead just return BLK_STS_OK as
the repair function has to continue to process the rest of the pages,
and the endio for the repair bio will do the appropriate cleanup for the
page that it was given.
CVE-2022-49168
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't BUG if someone dirty pages without asking ext4 first
[un]pin_user_pages_remote is dirtying pages without properly warning
the file system in advance. A related race was noted by Jan Kara in
2018[1]; however, more recently instead of it being a very hard-to-hit
race, it could be reliably triggered by process_vm_writev(2) which was
discovered by Syzbot[2].
This is technically a bug in mm/gup.c, but arguably ext4 is fragile in
that if some other kernel subsystem dirty pages without properly
notifying the file system using page_mkwrite(), ext4 will BUG, while
other file systems will not BUG (although data will still be lost).
So instead of crashing with a BUG, issue a warning (since there may be
potential data loss) and just mark the page as clean to avoid
unprivileged denial of service attacks until the problem can be
properly fixed. More discussion and background can be found in the
thread starting at [2].
[1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz
[2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com
CVE-2022-49171
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PM: core: keep irq flags in device_pm_check_callbacks()
The function device_pm_check_callbacks() can be called under the spin
lock (in the reported case it happens from genpd_add_device() ->
dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.
However this function uncoditionally uses spin_lock_irq() /
spin_unlock_irq(), thus not preserving the CPU flags. Use the
irqsave/irqrestore instead.
The backtrace for the reference:
[ 2.752010] ------------[ cut here ]------------
[ 2.756769] raw_local_irq_restore() called with IRQs enabled
[ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50
[ 2.772338] Modules linked in:
[ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684
[ 2.781384] Freeing initrd memory: 46024K
[ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50
[ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50
[ 2.785846] sp : ffff80000805b7d0
[ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002
[ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800
[ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00
[ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff
[ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7
[ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8
[ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0
[ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0
[ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000
[ 2.889774] Call trace:
[ 2.892290] warn_bogus_irq_restore+0x34/0x50
[ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0
[ 2.901690] genpd_unlock_spin+0x20/0x30
[ 2.905724] genpd_add_device+0x100/0x2d0
[ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c
[ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190
[ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0
[ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30
[ 2.929102] psci_dt_attach_cpu+0x24/0x90
[ 2.933230] psci_cpuidle_probe+0x2d4/0x46c
[ 2.937534] platform_probe+0x68/0xe0
[ 2.941304] really_probe.part.0+0x9c/0x2fc
[ 2.945605] __driver_probe_device+0x98/0x144
[ 2.950085] driver_probe_device+0x44/0x15c
[ 2.954385] __device_attach_driver+0xb8/0x120
[ 2.958950] bus_for_each_drv+0x78/0xd0
[ 2.962896] __device_attach+0xd8/0x180
[ 2.966843] device_initial_probe+0x14/0x20
[ 2.971144] bus_probe_device+0x9c/0xa4
[ 2.975092] device_add+0x380/0x88c
[ 2.978679] platform_device_add+0x114/0x234
[ 2.983067] platform_device_register_full+0x100/0x190
[ 2.988344] psci_idle_init+0x6c/0xb0
[ 2.992113] do_one_initcall+0x74/0x3a0
[ 2.996060] kernel_init_freeable+0x2fc/0x384
[ 3.000543] kernel_init+0x28/0x130
[ 3.004132] ret_from_fork+0x10/0x20
[ 3.007817] irq event stamp: 319826
[ 3.011404] hardirqs last enabled at (319825): [<ffffd40e7eda0268>] __up_console_sem+0x78/0x84
[ 3.020332] hardirqs last disabled at (319826): [<ffffd40e7fd6d9d8>] el1_dbg+0x24/0x8c
[ 3.028458] softirqs last enabled at (318312): [<ffffd40e7ec90410>] _stext+0x410/0x588
[ 3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>] __irq_exit_rcu+0x158/0x174
[ 3.045607] ---[ end trace 0000000000000000 ]---
CVE-2022-49175
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bfq: fix use-after-free in bfq_dispatch_request
KASAN reports a use-after-free report when doing normal scsi-mq test
[69832.239032] ==================================================================
[69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0
[69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155
[69832.244656]
[69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8
[69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[69832.249069] Workqueue: kblockd blk_mq_run_work_fn
[69832.250022] Call Trace:
[69832.250541] dump_stack+0x9b/0xce
[69832.251232] ? bfq_dispatch_request+0x1045/0x44b0
[69832.252243] print_address_description.constprop.6+0x3e/0x60
[69832.253381] ? __cpuidle_text_end+0x5/0x5
[69832.254211] ? vprintk_func+0x6b/0x120
[69832.254994] ? bfq_dispatch_request+0x1045/0x44b0
[69832.255952] ? bfq_dispatch_request+0x1045/0x44b0
[69832.256914] kasan_report.cold.9+0x22/0x3a
[69832.257753] ? bfq_dispatch_request+0x1045/0x44b0
[69832.258755] check_memory_region+0x1c1/0x1e0
[69832.260248] bfq_dispatch_request+0x1045/0x44b0
[69832.261181] ? bfq_bfqq_expire+0x2440/0x2440
[69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170
[69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830
[69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100
[69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0
[69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570
[69832.267147] ? __switch_to+0x5f4/0xee0
[69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140
[69832.268946] __blk_mq_run_hw_queue+0xc0/0x270
[69832.269840] blk_mq_run_work_fn+0x51/0x60
[69832.278170] process_one_work+0x6d4/0xfe0
[69832.278984] worker_thread+0x91/0xc80
[69832.279726] ? __kthread_parkme+0xb0/0x110
[69832.280554] ? process_one_work+0xfe0/0xfe0
[69832.281414] kthread+0x32d/0x3f0
[69832.282082] ? kthread_park+0x170/0x170
[69832.282849] ret_from_fork+0x1f/0x30
[69832.283573]
[69832.283886] Allocated by task 7725:
[69832.284599] kasan_save_stack+0x19/0x40
[69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0
[69832.286350] kmem_cache_alloc_node+0x13f/0x460
[69832.287237] bfq_get_queue+0x3d4/0x1140
[69832.287993] bfq_get_bfqq_handle_split+0x103/0x510
[69832.289015] bfq_init_rq+0x337/0x2d50
[69832.289749] bfq_insert_requests+0x304/0x4e10
[69832.290634] blk_mq_sched_insert_requests+0x13e/0x390
[69832.291629] blk_mq_flush_plug_list+0x4b4/0x760
[69832.292538] blk_flush_plug_list+0x2c5/0x480
[69832.293392] io_schedule_prepare+0xb2/0xd0
[69832.294209] io_schedule_timeout+0x13/0x80
[69832.295014] wait_for_common_io.constprop.1+0x13c/0x270
[69832.296137] submit_bio_wait+0x103/0x1a0
[69832.296932] blkdev_issue_discard+0xe6/0x160
[69832.297794] blk_ioctl_discard+0x219/0x290
[69832.298614] blkdev_common_ioctl+0x50a/0x1750
[69832.304715] blkdev_ioctl+0x470/0x600
[69832.305474] block_ioctl+0xde/0x120
[69832.306232] vfs_ioctl+0x6c/0xc0
[69832.306877] __se_sys_ioctl+0x90/0xa0
[69832.307629] do_syscall_64+0x2d/0x40
[69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[69832.309382]
[69832.309701] Freed by task 155:
[69832.310328] kasan_save_stack+0x19/0x40
[69832.311121] kasan_set_track+0x1c/0x30
[69832.311868] kasan_set_free_info+0x1b/0x30
[69832.312699] __kasan_slab_free+0x111/0x160
[69832.313524] kmem_cache_free+0x94/0x460
[69832.314367] bfq_put_queue+0x582/0x940
[69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0
[69832.317275] bfq_bfqq_expire+0xb27/0x2440
[69832.318084] bfq_dispatch_request+0x697/0x44b0
[69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830
[69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0
[69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140
[69832.322225] __blk_mq_run_hw_queue+0xc0/0x270
[69832.323114] blk_mq_run_work_fn+0x51/0x6
---truncated---
CVE-2022-49176
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: don't move oom_bfqq
Our test report a UAF:
[ 2073.019181] ==================================================================
[ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168
[ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584
[ 2073.019192]
[ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5
[ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 2073.019200] Call trace:
[ 2073.019203] dump_backtrace+0x0/0x310
[ 2073.019206] show_stack+0x28/0x38
[ 2073.019210] dump_stack+0xec/0x15c
[ 2073.019216] print_address_description+0x68/0x2d0
[ 2073.019220] kasan_report+0x238/0x2f0
[ 2073.019224] __asan_store8+0x88/0xb0
[ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168
[ 2073.019233] bfq_put_async_queues+0xbc/0x208
[ 2073.019236] bfq_pd_offline+0x178/0x238
[ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420
[ 2073.019244] bfq_exit_queue+0x128/0x178
[ 2073.019249] blk_mq_exit_sched+0x12c/0x160
[ 2073.019252] elevator_exit+0xc8/0xd0
[ 2073.019256] blk_exit_queue+0x50/0x88
[ 2073.019259] blk_cleanup_queue+0x228/0x3d8
[ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk]
[ 2073.019274] null_exit+0x90/0x114 [null_blk]
[ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0
[ 2073.019282] el0_svc_common+0xc8/0x320
[ 2073.019287] el0_svc_handler+0xf8/0x160
[ 2073.019290] el0_svc+0x10/0x218
[ 2073.019291]
[ 2073.019294] Allocated by task 14163:
[ 2073.019301] kasan_kmalloc+0xe0/0x190
[ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418
[ 2073.019308] bfq_pd_alloc+0x54/0x118
[ 2073.019313] blkcg_activate_policy+0x250/0x460
[ 2073.019317] bfq_create_group_hierarchy+0x38/0x110
[ 2073.019321] bfq_init_queue+0x6d0/0x948
[ 2073.019325] blk_mq_init_sched+0x1d8/0x390
[ 2073.019330] elevator_switch_mq+0x88/0x170
[ 2073.019334] elevator_switch+0x140/0x270
[ 2073.019338] elv_iosched_store+0x1a4/0x2a0
[ 2073.019342] queue_attr_store+0x90/0xe0
[ 2073.019348] sysfs_kf_write+0xa8/0xe8
[ 2073.019351] kernfs_fop_write+0x1f8/0x378
[ 2073.019359] __vfs_write+0xe0/0x360
[ 2073.019363] vfs_write+0xf0/0x270
[ 2073.019367] ksys_write+0xdc/0x1b8
[ 2073.019371] __arm64_sys_write+0x50/0x60
[ 2073.019375] el0_svc_common+0xc8/0x320
[ 2073.019380] el0_svc_handler+0xf8/0x160
[ 2073.019383] el0_svc+0x10/0x218
[ 2073.019385]
[ 2073.019387] Freed by task 72584:
[ 2073.019391] __kasan_slab_free+0x120/0x228
[ 2073.019394] kasan_slab_free+0x10/0x18
[ 2073.019397] kfree+0x94/0x368
[ 2073.019400] bfqg_put+0x64/0xb0
[ 2073.019404] bfqg_and_blkg_put+0x90/0xb0
[ 2073.019408] bfq_put_queue+0x220/0x228
[ 2073.019413] __bfq_put_async_bfqq+0x98/0x168
[ 2073.019416] bfq_put_async_queues+0xbc/0x208
[ 2073.019420] bfq_pd_offline+0x178/0x238
[ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420
[ 2073.019429] bfq_exit_queue+0x128/0x178
[ 2073.019433] blk_mq_exit_sched+0x12c/0x160
[ 2073.019437] elevator_exit+0xc8/0xd0
[ 2073.019440] blk_exit_queue+0x50/0x88
[ 2073.019443] blk_cleanup_queue+0x228/0x3d8
[ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk]
[ 2073.019459] null_exit+0x90/0x114 [null_blk]
[ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0
[ 2073.019467] el0_svc_common+0xc8/0x320
[ 2073.019471] el0_svc_handler+0xf8/0x160
[ 2073.019474] el0_svc+0x10/0x218
[ 2073.019475]
[ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00
which belongs to the cache kmalloc-1024 of size 1024
[ 2073.019484] The buggy address is located 552 bytes inside of
1024-byte region [ffff8000ccf63f00, ffff8000ccf64300)
[ 2073.019486] The buggy address belongs to the page:
[ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0
[ 2073.020123] flags: 0x7ffff0000008100(slab|head)
[ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00
[ 2073.020409] ra
---truncated---
CVE-2022-49179
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region
The device_node pointer is returned by of_parse_phandle() or
of_get_child_by_name() with refcount incremented.
We should use of_node_put() on it when done.
This function only call of_node_put(node) when of_address_to_resource
succeeds, missing error cases.
CVE-2022-49188
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kernel/resource: fix kfree() of bootmem memory again
Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem
memory"), we could get a resource allocated during boot via
alloc_resource(). And it's required to release the resource using
free_resource(). Howerver, many people use kfree directly which will
result in kernel BUG. In order to fix this without fixing every call
site, just leak a couple of bytes in such corner case.
CVE-2022-49190
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mxser: fix xmit_buf leak in activate when LSR == 0xff
When LSR is 0xff in ->activate() (rather unlike), we return an error.
Provided ->shutdown() is not called when ->activate() fails, nothing
actually frees the buffer in this case.
Fix this by properly freeing the buffer in a designated label. We jump
there also from the "!info->type" if now too.
CVE-2022-49191
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix use after free in remove_phb_dynamic()
In remove_phb_dynamic() we use &phb->io_resource, after we've called
device_unregister(&host_bridge->dev). But the unregister may have freed
phb, because pcibios_free_controller_deferred() is the release function
for the host_bridge.
If there are no outstanding references when we call device_unregister()
then phb will be freed out from under us.
This has gone mainly unnoticed, but with slub_debug and page_poison
enabled it can lead to a crash:
PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr"
#0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc
#1 [c0000000e4f075d0] oops_end at c000000000029608
#2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4
#3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8
#4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30
Data SLB Access [380] exception frame:
R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100
R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9
R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff
R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000
R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000
R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003
R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005
R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0
R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8
R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800
R30: c00000004d1d2400 R31: c00000004d1d2540
NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474
CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003
CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3
DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2
[NIP : release_resource+56]
[LR : release_resource+48]
#5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable)
#6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648
#7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io]
#8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io]
#9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c
#10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504
#11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868
#12 [c0000000e4f07c70] new_sync_write at c00000000054339c
#13 [c0000000e4f07d10] vfs_write at c000000000546624
#14 [c0000000e4f07d60] ksys_write at c0000000005469f4
#15 [c0000000e4f07db0] system_call_exception at c000000000030840
#16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168
To avoid it, we can take a reference to the host_bridge->dev until we're
done using phb. Then when we drop the reference the phb will be freed.
CVE-2022-49196
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
af_netlink: Fix shift out of bounds in group mask calculation
When a netlink message is received, netlink_recvmsg() fills in the address
of the sender. One of the fields is the 32-bit bitfield nl_groups, which
carries the multicast group on which the message was received. The least
significant bit corresponds to group 1, and therefore the highest group
that the field can represent is 32. Above that, the UB sanitizer flags the
out-of-bounds shift attempts.
Which bits end up being set in such case is implementation defined, but
it's either going to be a wrong non-zero value, or zero, which is at least
not misleading. Make the latter choice deterministic by always setting to 0
for higher-numbered multicast groups.
To get information about membership in groups >= 32, userspace is expected
to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO
socket option.
[0] https://lwn.net/Articles/147608/
The way to trigger this issue is e.g. through monitoring the BRVLAN group:
# bridge monitor vlan &
# ip link add name br type bridge
Which produces the following citation:
UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19
shift exponent 32 is too large for 32-bit type 'int'
CVE-2022-49197
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix double uncharge the mem of sk_msg
If tcp_bpf_sendmsg is running during a tear down operation, psock may be
freed.
tcp_bpf_sendmsg()
tcp_bpf_send_verdict()
sk_msg_return()
tcp_bpf_sendmsg_redir()
unlikely(!psock))
sk_msg_free()
The mem of msg has been uncharged in tcp_bpf_send_verdict() by
sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock
is null, we can simply returning an error code, this would then trigger
the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have
the side effect of throwing an error up to user space. This would be a
slight change in behavior from user side but would look the same as an
error if the redirect on the socket threw an error.
This issue can cause the following info:
WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
<TASK>
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
worker_thread+0x30/0x350
? process_one_work+0x3c0/0x3c0
kthread+0xe6/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x22/0x30
</TASK>
CVE-2022-49205
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full
If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.
Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.
This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
<TASK>
inet_csk_destroy_sock+0x55/0x110
__tcp_close+0x279/0x470
tcp_close+0x1f/0x60
inet_release+0x3f/0x80
__sock_release+0x3d/0xb0
sock_close+0x11/0x20
__fput+0x92/0x250
task_work_run+0x6a/0xa0
do_exit+0x33b/0xb60
do_group_exit+0x2f/0xa0
get_signal+0xb6/0x950
arch_do_signal_or_restart+0xac/0x2a0
exit_to_user_mode_prepare+0xa9/0x200
syscall_exit_to_user_mode+0x12/0x30
do_syscall_64+0x46/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
</TASK>
WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
<TASK>
__sk_destruct+0x24/0x1f0
sk_psock_destroy+0x19b/0x1c0
process_one_work+0x1b3/0x3c0
kthread+0xe6/0x110
ret_from_fork+0x22/0x30
</TASK>
CVE-2022-49209
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init
The reference counting issue happens in several error handling paths
on a refcounted object "nc->dmac". In these paths, the function simply
returns the error code, forgetting to balance the reference count of
"nc->dmac", increased earlier by dma_request_channel(), which may
cause refcount leaks.
Fix it by decrementing the refcount of specific object in those error
paths.
CVE-2022-49212
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: Fix reference leak in tegra_dsi_ganged_probe
The reference taken by 'of_find_device_by_node()' must be released when
not needed anymore. Add put_device() call to fix this.
CVE-2022-49216
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix abort all task initialization
In pm80xx_send_abort_all(), the n_elem field of the ccb used is not
initialized to 0. This missing initialization sometimes lead to the task
completion path seeing the ccb with a non-zero n_elem resulting in the
execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),
causing a crash such as:
[ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280
[ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012
[ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0
[ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0
[ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b
[ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000
[ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000
[ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000
[ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0
[ 197.762656] Call Trace:
[ 197.765127] <IRQ>
[ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]
[ 197.772364] ? do_raw_spin_unlock+0x54/0x220
[ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]
[ 197.782406] process_oq+0xe85/0x7890 [pm80xx]
[ 197.786817] ? lock_acquire+0x194/0x490
[ 197.790697] ? handle_irq_event+0x10e/0x1b0
[ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]
[ 197.800378] ? __wake_up_bit+0x100/0x100
[ 197.804340] ? lock_is_held_type+0x98/0x110
[ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx]
[ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0
[ 197.818785] __do_softirq+0x1b5/0x82d
[ 197.822485] ? do_raw_spin_unlock+0x54/0x220
[ 197.826799] __irq_exit_rcu+0x17e/0x1e0
[ 197.830678] irq_exit_rcu+0xa/0x20
[ 197.834114] common_interrupt+0x78/0x90
[ 197.840051] </IRQ>
[ 197.844236] <TASK>
[ 197.848397] asm_common_interrupt+0x1e/0x40
Avoid this issue by always initializing the ccb n_elem field to 0 in
pm8001_send_abort_all(), pm8001_send_read_log() and
pm80xx_send_abort_all().
CVE-2022-49217
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dax: make sure inodes are flushed before destroy cache
A bug can be triggered by following command
$ modprobe nd_pmem && modprobe -r nd_pmem
[ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()
[ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)
[ 10.062433] Call Trace:
[ 10.062673] dump_stack_lvl+0x34/0x44
[ 10.062865] slab_err+0x90/0xd0
[ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0
[ 10.063848] kmem_cache_destroy+0x4a/0x110
[ 10.064058] __x64_sys_delete_module+0x265/0x300
This is caused by dax_fs_exit() not flushing inodes before destroy cache.
To fix this issue, call rcu_barrier() before destroy cache.
CVE-2022-49220
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: asix: add proper error handling of usb read errors
Syzbot once again hit uninit value in asix driver. The problem still the
same -- asix_read_cmd() reads less bytes, than was requested by caller.
Since all read requests are performed via asix_read_cmd() let's catch
usb related error there and add __must_check notation to be sure all
callers actually check return value.
So, this patch adds sanity check inside asix_read_cmd(), that simply
checks if bytes read are not less, than was requested and adds missing
error handling of asix_read_cmd() all across the driver code.
CVE-2022-49226
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()
In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()
is assigned to mode and is passed to drm_mode_probed_add() directly after
that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and
there is a dereference of it in list_add_tail() without recoveries, which
could lead to NULL pointer dereference on failure of
amdgpu_dm_create_common_mode().
Fix this by adding a NULL check of mode.
This bug was found by a static analyzer.
Builds with 'make allyesconfig' show no new warnings,
and our static analyzer no longer warns about this code.
CVE-2022-49232
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ath9k_htc: fix uninit value bugs
Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing
field initialization.
In htc_connect_service() svc_meta_len and pad are not initialized. Based
on code it looks like in current skb there is no service data, so simply
initialize svc_meta_len to 0.
htc_issue_send() does not initialize htc_frame_hdr::control array. Based
on firmware code, it will initialize it by itself, so simply zero whole
array to make KMSAN happy
Fail logs:
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...
Bytes 4-7 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...
Bytes 16-17 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00
CVE-2022-49235
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA:
firewire-lib: Add support for deferred transaction") while 'deferrable'
flag can be uninitialized for non-control/notify AV/C transactions.
UBSAN reports it:
kernel: ================================================================================
kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9
kernel: load of value 158 is not a valid value for type '_Bool'
kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu
kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019
kernel: Call Trace:
kernel: <IRQ>
kernel: show_stack+0x52/0x58
kernel: dump_stack_lvl+0x4a/0x5f
kernel: dump_stack+0x10/0x12
kernel: ubsan_epilogue+0x9/0x45
kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49
kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]
kernel: fcp_response+0x28/0x30 [snd_firewire_lib]
kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core]
kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci]
kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]
kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core]
kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]
kernel: tasklet_action_common.constprop.0+0xea/0xf0
kernel: tasklet_action+0x22/0x30
kernel: __do_softirq+0xd9/0x2e3
kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0
kernel: do_softirq+0x75/0xa0
kernel: </IRQ>
kernel: <TASK>
kernel: __local_bh_enable_ip+0x50/0x60
kernel: irq_forced_thread_fn+0x7e/0x90
kernel: irq_thread+0xba/0x190
kernel: ? irq_thread_fn+0x60/0x60
kernel: kthread+0x11e/0x140
kernel: ? irq_thread_check_affinity+0xf0/0xf0
kernel: ? set_kthread_struct+0x50/0x50
kernel: ret_from_fork+0x22/0x30
kernel: </TASK>
kernel: ================================================================================
This commit fixes the bug. The bug has no disadvantage for the non-
control/notify AV/C transactions since the flag has an effect for AV/C
response with INTERIM (0x0f) status which is not used for the transactions
in AV/C general specification.
CVE-2022-49248
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: usb: go7007: s2250-board: fix leak in probe()
Call i2c_unregister_device(audio) on this error path.
CVE-2022-49253
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
block: don't delete queue kobject before its children
kobjects aren't supposed to be deleted before their child kobjects are
deleted. Apparently this is usually benign; however, a WARN will be
triggered if one of the child kobjects has a named attribute group:
sysfs group 'modes' not found for kobject 'crypto'
WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80
...
Call Trace:
sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312
__kobject_del+0x20/0x80 lib/kobject.c:611
kobject_cleanup+0xa4/0x140 lib/kobject.c:696
kobject_release lib/kobject.c:736 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x53/0x70 lib/kobject.c:753
blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159
blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962
del_gendisk+0x117/0x250 block/genhd.c:610
Fix this by moving the kobject_del() and the corresponding
kobject_uevent() to the correct place.
CVE-2022-49259
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
exec: Force single empty string when argv is empty
Quoting[1] Ariadne Conill:
"In several other operating systems, it is a hard requirement that the
second argument to execve(2) be the name of a program, thus prohibiting
a scenario where argc < 1. POSIX 2017 also recommends this behaviour,
but it is not an explicit requirement[2]:
The argument arg0 should point to a filename string that is
associated with the process being started by one of the exec
functions.
...
Interestingly, Michael Kerrisk opened an issue about this in 2008[3],
but there was no consensus to support fixing this issue then.
Hopefully now that CVE-2021-4034 shows practical exploitative use[4]
of this bug in a shellcode, we can reconsider.
This issue is being tracked in the KSPP issue tracker[5]."
While the initial code searches[6][7] turned up what appeared to be
mostly corner case tests, trying to that just reject argv == NULL
(or an immediately terminated pointer list) quickly started tripping[8]
existing userspace programs.
The next best approach is forcing a single empty string into argv and
adjusting argc to match. The number of programs depending on argc == 0
seems a smaller set than those calling execve with a NULL argv.
Account for the additional stack space in bprm_stack_limits(). Inject an
empty string when argc == 0 (and set argc = 1). Warn about the case so
userspace has some notice about the change:
process './argc0' launched './argc0' with NULL argv: empty string added
Additionally WARN() and reject NULL argv usage for kernel threads.
[1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
[3] https://bugzilla.kernel.org/show_bug.cgi?id=8408
[4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
[5] https://github.com/KSPP/linux/issues/176
[6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0
[7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0
[8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/
CVE-2022-49264
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent bad output lengths in smb2_ioctl_query_info()
When calling smb2_ioctl_query_info() with
smb_query_info::flags=PASSTHRU_FSCTL and
smb_query_info::output_buffer_length=0, the following would return
0x10
buffer = memdup_user(arg + sizeof(struct smb_query_info),
qi.output_buffer_length);
if (IS_ERR(buffer)) {
kfree(vars);
return PTR_ERR(buffer);
}
rather than a valid pointer thus making IS_ERR() check fail. This
would then cause a NULL ptr deference in @buffer when accessing it
later in smb2_ioctl_query_ioctl(). While at it, prevent having a
@buffer smaller than 8 bytes to correctly handle SMB2_SET_INFO
FileEndOfFileInformation requests when
smb_query_info::flags=PASSTHRU_SET_INFO.
Here is a small C reproducer which triggers a NULL ptr in @buffer when
passing an invalid smb_query_info::flags
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#define die(s) perror(s), exit(1)
#define QUERY_INFO 0xc018cf07
int main(int argc, char *argv[])
{
int fd;
if (argc < 2)
exit(1);
fd = open(argv[1], O_RDONLY);
if (fd == -1)
die("open");
if (ioctl(fd, QUERY_INFO, (uint32_t[]) { 0, 0, 0, 4, 0, 0}) == -1)
die("ioctl");
close(fd);
return 0;
}
mount.cifs //srv/share /mnt -o ...
gcc repro.c && ./a.out /mnt/f0
[ 114.138620] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ 114.139310] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 114.139775] CPU: 2 PID: 995 Comm: a.out Not tainted 5.17.0-rc8 #1
[ 114.140148] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[ 114.140818] RIP: 0010:smb2_ioctl_query_info+0x206/0x410 [cifs]
[ 114.141221] Code: 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 c8 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 7b 28 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9c 01 00 00 49 8b 3f e8 58 02 fb ff 48 8b 14 24
[ 114.142348] RSP: 0018:ffffc90000b47b00 EFLAGS: 00010256
[ 114.142692] RAX: dffffc0000000000 RBX: ffff888115503200 RCX: ffffffffa020580d
[ 114.143119] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffa043a380
[ 114.143544] RBP: ffff888115503278 R08: 0000000000000001 R09: 0000000000000003
[ 114.143983] R10: fffffbfff4087470 R11: 0000000000000001 R12: ffff888115503288
[ 114.144424] R13: 00000000ffffffea R14: ffff888115503228 R15: 0000000000000000
[ 114.144852] FS: 00007f7aeabdf740(0000) GS:ffff888151600000(0000) knlGS:0000000000000000
[ 114.145338] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 114.145692] CR2: 00007f7aeacfdf5e CR3: 000000012000e000 CR4: 0000000000350ee0
[ 114.146131] Call Trace:
[ 114.146291] <TASK>
[ 114.146432] ? smb2_query_reparse_tag+0x890/0x890 [cifs]
[ 114.146800] ? cifs_mapchar+0x460/0x460 [cifs]
[ 114.147121] ? rcu_read_lock_sched_held+0x3f/0x70
[ 114.147412] ? cifs_strndup_to_utf16+0x15b/0x250 [cifs]
[ 114.147775] ? dentry_path_raw+0xa6/0xf0
[ 114.148024] ? cifs_convert_path_to_utf16+0x198/0x220 [cifs]
[ 114.148413] ? smb2_check_message+0x1080/0x1080 [cifs]
[ 114.148766] ? rcu_read_lock_sched_held+0x3f/0x70
[ 114.149065] cifs_ioctl+0x1577/0x3320 [cifs]
[ 114.149371] ? lock_downgrade+0x6f0/0x6f0
[ 114.149631] ? cifs_readdir+0x2e60/0x2e60 [cifs]
[ 114.149956] ? rcu_read_lock_sched_held+0x3f/0x70
[ 114.150250] ? __rseq_handle_notify_resume+0x80b/0xbe0
[ 114.150562] ? __up_read+0x192/0x710
[ 114.150791] ? __ia32_sys_rseq+0xf0/0xf0
[ 114.151025] ? __x64_sys_openat+0x11f/0x1d0
[ 114.151296] __x64_sys_ioctl+0x127/0x190
[ 114.151549] do_syscall_64+0x3b/0x90
[ 114.151768] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 114.152079] RIP: 0033:0x7f7aead043df
[ 114.152306] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24
---truncated---
CVE-2022-49271
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: m_can: m_can_tx_handler(): fix use after free of skb
can_put_echo_skb() will clone skb then free the skb. Move the
can_put_echo_skb() for the m_can version 3.0.x directly before the
start of the xmit in hardware, similar to the 3.1.x branch.
CVE-2022-49275
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
NFSD: prevent underflow in nfssvc_decode_writeargs()
Smatch complains:
fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()
warn: no lower bound on 'args->len'
Change the type to unsigned to prevent this issue.
CVE-2022-49280
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix handlecache and multiuser
In multiuser each individual user has their own tcon structure for the
share and thus their own handle for a cached directory.
When we umount such a share we much make sure to release the pinned down dentry
for each such tcon and not just the master tcon.
Otherwise we will get nasty warnings on umount that dentries are still in use:
[ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\
(2) [unmount of cifs cifs]
...
[ 3459.590492] Call Trace:
[ 3459.590500] d_walk+0x61/0x2a0
[ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0
[ 3459.590526] shrink_dcache_for_umount+0x49/0x110
[ 3459.590535] generic_shutdown_super+0x1a/0x110
[ 3459.590542] kill_anon_super+0x14/0x30
[ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs]
[ 3459.590773] deactivate_locked_super+0x36/0xa0
[ 3459.590782] cleanup_mnt+0x131/0x190
[ 3459.590789] task_work_run+0x5c/0x90
[ 3459.590798] exit_to_user_mode_loop+0x151/0x160
[ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0
[ 3459.590818] syscall_exit_to_user_mode+0x12/0x30
[ 3459.590828] do_syscall_64+0x48/0x90
[ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2022-49281
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tpm: use try_get_ops() in tpm-space.c
As part of the series conversion to remove nested TPM operations:
https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/
exposure of the chip->tpm_mutex was removed from much of the upper
level code. In this conversion, tpm2_del_space() was missed. This
didn't matter much because it's usually called closely after a
converted operation, so there's only a very tiny race window where the
chip can be removed before the space flushing is done which causes a
NULL deref on the mutex. However, there are reports of this window
being hit in practice, so fix this by converting tpm2_del_space() to
use tpm_try_get_ops(), which performs all the teardown checks before
acquring the mutex.
CVE-2022-49286
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix potential double free on mesh join
While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving
mesh") fixed a memory leak on mesh leave / teardown it introduced a
potential memory corruption caused by a double free when rejoining the
mesh:
ieee80211_leave_mesh()
-> kfree(sdata->u.mesh.ie);
...
ieee80211_join_mesh()
-> copy_mesh_setup()
-> old_ie = ifmsh->ie;
-> kfree(old_ie);
This double free / kernel panics can be reproduced by using wpa_supplicant
with an encrypted mesh (if set up without encryption via "iw" then
ifmsh->ie is always NULL, which avoids this issue). And then calling:
$ iw dev mesh0 mesh leave
$ iw dev mesh0 mesh join my-mesh
Note that typically these commands are not used / working when using
wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going
through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join
where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of
default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids
the memory corruption, too.
The issue was first observed in an application which was not using
wpa_supplicant but "Senf" instead, which implements its own calls to
nl80211.
Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh
join function and leaving it solely up to the mesh leave to free the
mesh IE.
CVE-2022-49290
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: oss: Fix PCM OSS buffer allocation overflow
We've got syzbot reports hitting INT_MAX overflow at vmalloc()
allocation that is called from snd_pcm_plug_alloc(). Although we
apply the restrictions to input parameters, it's based only on the
hw_params of the underlying PCM device. Since the PCM OSS layer
allocates a temporary buffer for the data conversion, the size may
become unexpectedly large when more channels or higher rates is given;
in the reported case, it went over INT_MAX, hence it hits WARN_ON().
This patch is an attempt to avoid such an overflow and an allocation
for too large buffers. First off, it adds the limit of 1MB as the
upper bound for period bytes. This must be large enough for all use
cases, and we really don't want to handle a larger temporary buffer
than this size. The size check is performed at two places, where the
original period bytes is calculated and where the plugin buffer size
is calculated.
In addition, the driver uses array_size() and array3_size() for
multiplications to catch overflows for the converted period size and
buffer bytes.
CVE-2022-49292
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nbd: call genl_unregister_family() first in nbd_cleanup()
Otherwise there may be race between module removal and the handling of
netlink command, which can lead to the oops as shown below:
BUG: kernel NULL pointer dereference, address: 0000000000000098
Oops: 0002 [#1] SMP PTI
CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:down_write+0x1a/0x50
Call Trace:
start_creating+0x89/0x130
debugfs_create_dir+0x1b/0x130
nbd_start_device+0x13d/0x390 [nbd]
nbd_genl_connect+0x42f/0x748 [nbd]
genl_family_rcv_msg_doit.isra.0+0xec/0x150
genl_rcv_msg+0xe5/0x1e0
netlink_rcv_skb+0x55/0x100
genl_rcv+0x29/0x40
netlink_unicast+0x1a8/0x250
netlink_sendmsg+0x21b/0x430
____sys_sendmsg+0x2a4/0x2d0
___sys_sendmsg+0x81/0xc0
__sys_sendmsg+0x62/0xb0
__x64_sys_sendmsg+0x1f/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Modules linked in: nbd(E-)
CVE-2022-49295
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix io hung while disconnecting device
In our tests, "qemu-nbd" triggers a io hung:
INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000
Call Trace:
<TASK>
__schedule+0x480/0x1050
? _raw_spin_lock_irqsave+0x3e/0xb0
schedule+0x9c/0x1b0
blk_mq_freeze_queue_wait+0x9d/0xf0
? ipi_rseq+0x70/0x70
blk_mq_freeze_queue+0x2b/0x40
nbd_add_socket+0x6b/0x270 [nbd]
nbd_ioctl+0x383/0x510 [nbd]
blkdev_ioctl+0x18e/0x3e0
__x64_sys_ioctl+0xac/0x120
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fd8ff706577
RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577
RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f
RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0
R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d
R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0
"qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following
message was found:
block nbd0: Send disconnect failed -32
Which indicate that something is wrong with the server. Then,
"qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear
requests after commit 2516ab1543fd("nbd: only clear the queue on device
teardown"). And in the meantime, request can't complete through timeout
because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which
means such request will never be completed in this situation.
Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't
complete multiple times, switch back to call nbd_clear_sock() in
nbd_clear_sock_ioctl(), so that inflight requests can be cleared.
CVE-2022-49297
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix race between nbd_alloc_config() and module removal
When nbd module is being removing, nbd_alloc_config() may be
called concurrently by nbd_genl_connect(), although try_module_get()
will return false, but nbd_alloc_config() doesn't handle it.
The race may lead to the leak of nbd_config and its related
resources (e.g, recv_workq) and oops in nbd_read_stat() due
to the unload of nbd module as shown below:
BUG: kernel NULL pointer dereference, address: 0000000000000040
Oops: 0000 [#1] SMP PTI
CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: knbd16-recv recv_work [nbd]
RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd]
Call Trace:
recv_work+0x3b/0xb0 [nbd]
process_one_work+0x1ed/0x390
worker_thread+0x4a/0x3d0
kthread+0x12a/0x150
ret_from_fork+0x22/0x30
Fixing it by checking the return value of try_module_get()
in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV),
assign nbd->config only when nbd_alloc_config() succeeds to ensure
the value of nbd->config is binary (valid or NULL).
Also adding a debug message to check the reference counter
of nbd_config during module removal.
CVE-2022-49300
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()
There is a deadlock in ieee80211_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2)
| ieee80211_send_beacon()
ieee80211_beacons_stop() | mod_timer()
spin_lock_irqsave() //(1) | (wait a time)
... | ieee80211_send_beacon_cb()
del_timer_sync() | spin_lock_irqsave() //(2)
(wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use
del_timer_sync() to wait timer to stop, but timer handler
also need ieee->beacon_lock in position (2) of thread 2.
As a result, ieee80211_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_irqsave(), which could let timer handler to obtain
the needed lock.
CVE-2022-49305
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
extcon: Modify extcon device to be created after driver data is set
Currently, someone can invoke the sysfs such as state_show()
intermittently before dev_set_drvdata() is done.
And it can be a cause of kernel Oops because of edev is Null at that time.
So modified the driver registration to after setting drviver data.
- Oops's backtrace.
Backtrace:
[<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show)
[<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show)
[<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show)
[<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read)
[<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read)
[<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read)
[<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read)
[<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read)
[<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read)
[<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)
CVE-2022-49308
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers: usb: host: Fix deadlock in oxu_bus_suspend()
There is a deadlock in oxu_bus_suspend(), which is shown below:
(Thread 1) | (Thread 2)
| timer_action()
oxu_bus_suspend() | mod_timer()
spin_lock_irq() //(1) | (wait a time)
... | oxu_watchdog()
del_timer_sync() | spin_lock_irq() //(2)
(wait timer to stop) | ...
We hold oxu->lock in position (1) of thread 1, and use
del_timer_sync() to wait timer to stop, but timer handler
also need oxu->lock in position (2) of thread 2. As a result,
oxu_bus_suspend() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_irq(), which could let timer handler to obtain
the needed lock.
CVE-2022-49313
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVE-2022-49319
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type
In zynqmp_dma_alloc/free_chan_resources functions there is a
potential overflow in the below expressions.
dma_alloc_coherent(chan->dev, (2 * chan->desc_size *
ZYNQMP_DMA_NUM_DESCS),
&chan->desc_pool_p, GFP_KERNEL);
dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) *
ZYNQMP_DMA_NUM_DESCS),
chan->desc_pool_v, chan->desc_pool_p);
The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though
this overflow condition is not observed but it is a potential problem
in the case of 32-bit multiplication. Hence fix it by changing the
desc_size data type to size_t.
In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in
dma_alloc_coherent API argument.
Addresses-Coverity: Event overflow_before_widen.
CVE-2022-49320
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: treat all calls not a bcall when bc_serv is NULL
When a rdma server returns a fault format reply, nfs v3 client may
treats it as a bcall when bc service is not exist.
The debug message at rpcrdma_bc_receive_call are,
[56579.837169] RPC: rpcrdma_bc_receive_call: callback XID
00000001, length=20
[56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 04
After that, rpcrdma_bc_receive_call will meets NULL pointer as,
[ 226.057890] BUG: unable to handle kernel NULL pointer dereference at
00000000000000c8
...
[ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20
...
[ 226.059732] Call Trace:
[ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma]
[ 226.060011] __ib_process_cq+0x89/0x170 [ib_core]
[ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core]
[ 226.060257] process_one_work+0x1a7/0x360
[ 226.060367] ? create_worker+0x1a0/0x1a0
[ 226.060440] worker_thread+0x30/0x390
[ 226.060500] ? create_worker+0x1a0/0x1a0
[ 226.060574] kthread+0x116/0x130
[ 226.060661] ? kthread_flush_work_fn+0x10/0x10
[ 226.060724] ret_from_fork+0x35/0x40
...
CVE-2022-49321
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
be triggered.
Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
[<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x60/0x8c
dump_stack+0x10/0x12
__might_resched.cold+0x11d/0x155
rt_spin_lock+0x40/0x70
trace_event_buffer_commit+0x2fa/0x4c0
? map_vsyscall+0x93/0x93
trace_event_raw_event_initcall_start+0xbe/0x110
? perf_trace_initcall_finish+0x210/0x210
? probe_sched_wakeup+0x34/0x40
? ttwu_do_wakeup+0xda/0x310
? trace_hardirqs_on+0x35/0x170
? map_vsyscall+0x93/0x93
do_one_initcall+0x217/0x3c0
? trace_event_raw_event_initcall_level+0x170/0x170
? push_cpu_stop+0x400/0x400
? cblist_init_generic+0x241/0x290
kernel_init_freeable+0x1ac/0x347
? _raw_spin_unlock_irq+0x65/0x80
? rest_init+0xf0/0xf0
kernel_init+0x1e/0x150
ret_from_fork+0x22/0x30
</TASK>
CVE-2022-49322
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.
CVE-2022-49323
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: add accessors to read/set tp->snd_cwnd
We had various bugs over the years with code
breaking the assumption that tp->snd_cwnd is greater
than zero.
Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) added
in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")
can trigger, and without a repro we would have to spend
considerable time finding the bug.
Instead of complaining too late, we want to catch where
and when tp->snd_cwnd is set to an illegal value.
CVE-2022-49325
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rtl818x: Prevent using not initialized queues
Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.
Ignore the skb priority for those cards, they only have one tx queue. Pierre
Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:
https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html
He also confirmed that this patch fixes the issue. In summary this happened:
After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a
"divide error: 0000" when connecting to an AP. Control port tx now tries to
use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in
2.10.
Since only the rtl8187se part of the driver supports QoS, the priority
of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185
cards.
rtl8180 is then unconditionally reading out the priority and finally crashes on
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this
patch:
idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries
"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got
initialized.
CVE-2022-49326
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
syzbot got a new report [1] finally pointing to a very old bug,
added in initial support for MTU probing.
tcp_mtu_probe() has checks about starting an MTU probe if
tcp_snd_cwnd(tp) >= 11.
But nothing prevents tcp_snd_cwnd(tp) to be reduced later
and before the MTU probe succeeds.
This bug would lead to potential zero-divides.
Debugging added in commit 40570375356c ("tcp: add accessors
to read/set tp->snd_cwnd") has paid off :)
While we are at it, address potential overflows in this code.
[1]
WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Modules linked in:
CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356
tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861
tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973
tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476
sk_backlog_rcv include/net/sock.h:1061 [inline]
__release_sock+0x1d8/0x4c0 net/core/sock.c:2849
release_sock+0x5d/0x1c0 net/core/sock.c:3404
sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145
tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410
tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
__sys_sendto+0x439/0x5c0 net/socket.c:2119
__do_sys_sendto net/socket.c:2131 [inline]
__se_sys_sendto net/socket.c:2127 [inline]
__x64_sys_sendto+0xda/0xf0 net/socket.c:2127
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f6431289109
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109
RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a
RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000
CVE-2022-49330
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
Error paths do not free previously allocated memory. Add devm_kfree() to
those failure paths.
CVE-2022-49331
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Address NULL pointer dereference after starget_to_rport()
Calls to starget_to_rport() may return NULL. Add check for NULL rport
before dereference.
CVE-2022-49332
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.
Submitting a cs with 0 chunks, causes an oops later, found trying
to execute the wrong userspace driver.
MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo
[172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8
[172536.665188] #PF: supervisor read access in kernel mode
[172536.665189] #PF: error_code(0x0000) - not-present page
[172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0
[172536.665195] Oops: 0000 [#1] SMP NOPTI
[172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS
[172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015
[172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu]
[172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10
[172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246
[172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68
[172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38
[172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40
[172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28
[172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000
[172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0
[172536.665287] Call Trace:
[172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm]
[172536.665338] drm_ioctl+0x201/0x3b0 [drm]
[172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[172536.665372] ? selinux_file_ioctl+0x135/0x230
[172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[172536.665403] __x64_sys_ioctl+0x83/0xb0
[172536.665406] do_syscall_64+0x33/0x40
[172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
CVE-2022-49335
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_lock failed, it didn't clean up the flags it set
before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of
lock is still in used, next time when unlink invokes this function, it
will return succeed, and then unlink will remove inode and dentry if lock
is not in used(file closed), but the dlm lock is still linked in dlm lock
resource, then when bast come in, it will trigger a panic due to
user-after-free. See the following panic call trace. To fix this,
USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should
be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink
fail.
For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,
USER_LOCK_BUSY is also required to be cleared. Even though spin lock is
released in between, but USER_LOCK_IN_TEARDOWN is still set, for
USER_LOCK_BUSY, if before every place that waits on this flag,
USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow
waits on the busy flag set by user_dlm_destroy_lock(), then we can
simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix
user_dlm_cluster_lock() which is the only function not following this.
[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink
004fb0000060000b5a90b8c847b72e1, error -16 from destroy
[ 989.757536] ------------[ cut here ]------------
[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!
[ 989.757876] invalid opcode: 0000 [#1] SMP
[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)
ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc
xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5
auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs
ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc
fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc
rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad
rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)
mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad
ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support
pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si
ipmi_msghandler
[ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp
pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel
be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio
libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi
dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
ksplice_2zhuk2jr_ib_ipoib_old]
[ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE
4.1.12-124.57.1.el6uek.x86_64 #2
[ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021
[ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:
ffff88017f7c8000
[ 989.762848] RIP: e030:[<ffffffffc07d4316>] [<ffffffffc07d4316>]
__user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]
[ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246
[ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:
0000000000000003
[ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:
ffff880174d48170
[ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:
0000000000000000
[ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:
ffff880174d48008
[ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:
ffff88021db7a000
[ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)
knlGS:ffff880247480000
[ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:
0000000000042660
[ 989.765081] Stack:
[ 989.765167] 00000000000
---truncated---
CVE-2022-49337
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix a data-race in unix_dgram_peer_wake_me().
unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s
lock held and check if its receive queue is full. Here we need to
use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise
KCSAN will report a data-race.
CVE-2022-49344
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on in ext4_writepages
we got issue as follows:
EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls
------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2708!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155
RIP: 0010:ext4_writepages+0x1977/0x1c10
RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000
RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002
RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000
R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001
R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028
FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
do_writepages+0x130/0x3a0
filemap_fdatawrite_wbc+0x83/0xa0
filemap_flush+0xab/0xe0
ext4_alloc_da_blocks+0x51/0x120
__ext4_ioctl+0x1534/0x3210
__x64_sys_ioctl+0x12c/0x170
do_syscall_64+0x3b/0x90
It may happen as follows:
1. write inline_data inode
vfs_write
new_sync_write
ext4_file_write_iter
ext4_buffered_write_iter
generic_perform_write
ext4_da_write_begin
ext4_da_write_inline_data_begin -> If inline data size too
small will allocate block to write, then mapping will has
dirty page
ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA
2. fallocate
do_vfs_ioctl
ioctl_preallocate
vfs_fallocate
ext4_fallocate
ext4_convert_inline_data
ext4_convert_inline_data_nolock
ext4_map_blocks -> fail will goto restore data
ext4_restore_inline_data
ext4_create_inline_data
ext4_write_inline_data
ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA
3. writepages
__ext4_ioctl
ext4_alloc_da_blocks
filemap_flush
filemap_fdatawrite_wbc
do_writepages
ext4_writepages
if (ext4_has_inline_data(inode))
BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
The root cause of this issue is we destory inline data until call
ext4_writepages under delay allocation mode. But there maybe already
convert from inline to extent. To solve this issue, we call
filemap_flush first..
CVE-2022-49347
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix use-after-free in ext4_rename_dir_prepare
We got issue as follows:
EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue
ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478
ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000
ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae
==================================================================
BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220
Read of size 4 at addr ffff88810beee6ae by task rep/1895
CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241
Call Trace:
dump_stack+0xbe/0xf9
print_address_description.constprop.0+0x1e/0x220
kasan_report.cold+0x37/0x7f
ext4_rename_dir_prepare+0x152/0x220
ext4_rename+0xf44/0x1ad0
ext4_rename2+0x11c/0x170
vfs_rename+0xa84/0x1440
do_renameat2+0x683/0x8f0
__x64_sys_renameat+0x53/0x60
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f45a6fc41c9
RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9
RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005
RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080
R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0
R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000
The buggy address belongs to the page:
page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee
flags: 0x200000000000000()
raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000
raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
Disabling lock debugging due to kernel taint
ext4_rename_dir_prepare: [2] parent_de->inode=3537895424
ext4_rename_dir_prepare: [3] dir=0xffff888124170140
ext4_rename_dir_prepare: [4] ino=2
ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872
Reason is first directory entry which 'rec_len' is 34478, then will get illegal
parent entry. Now, we do not check directory entry after read directory block
in 'ext4_get_first_dir_block'.
To solve this issue, check directory entry in 'ext4_get_first_dir_block'.
[ Trigger an ext4_error() instead of just warning if the directory is
missing a '.' or '..' entry. Also make sure we return an error code
if the file system is corrupted. -TYT ]
CVE-2022-49349
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: altera: Fix refcount leak in altera_tse_mdio_create
Every iteration of for_each_child_of_node() decrements
the reference count of the previous node.
When break from a for_each_child_of_node() loop,
we need to explicitly call of_node_put() on the child node when
not need anymore.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-49351
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().
We don't need the device node after it.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-49367
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle
kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Fix this issue by calling kobject_put().
CVE-2022-49370
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev) // get lock dev
async_schedule_dev(__device_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__device_attach_async_helper will get lock dev as
well, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
CVE-2022-49371
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_rtx_synack() can be called from process context
Laurent reported the enclosed report [1]
This bug triggers with following coditions:
0) Kernel built with CONFIG_DEBUG_PREEMPT=y
1) A new passive FastOpen TCP socket is created.
This FO socket waits for an ACK coming from client to be a complete
ESTABLISHED one.
2) A socket operation on this socket goes through lock_sock()
release_sock() dance.
3) While the socket is owned by the user in step 2),
a retransmit of the SYN is received and stored in socket backlog.
4) At release_sock() time, the socket backlog is processed while
in process context.
5) A SYNACK packet is cooked in response of the SYN retransmit.
6) -> tcp_rtx_synack() is called in process context.
Before blamed commit, tcp_rtx_synack() was always called from BH handler,
from a timer handler.
Fix this by using TCP_INC_STATS() & NET_INC_STATS()
which do not assume caller is in non preemptible context.
[1]
BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
caller is tcp_rtx_synack.part.0+0x36/0xc0
CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1
Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
Call Trace:
<TASK>
dump_stack_lvl+0x48/0x5e
check_preemption_disabled+0xde/0xe0
tcp_rtx_synack.part.0+0x36/0xc0
tcp_rtx_synack+0x8d/0xa0
? kmem_cache_alloc+0x2e0/0x3e0
? apparmor_file_alloc_security+0x3b/0x1f0
inet_rtx_syn_ack+0x16/0x30
tcp_check_req+0x367/0x610
tcp_rcv_state_process+0x91/0xf60
? get_nohz_timer_target+0x18/0x1a0
? lock_timer_base+0x61/0x80
? preempt_count_add+0x68/0xa0
tcp_v4_do_rcv+0xbd/0x270
__release_sock+0x6d/0xb0
release_sock+0x2b/0x90
sock_setsockopt+0x138/0x1140
? __sys_getsockname+0x7e/0xc0
? aa_sk_perm+0x3e/0x1a0
__sys_setsockopt+0x198/0x1e0
__x64_sys_setsockopt+0x21/0x30
do_syscall_64+0x38/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2022-49372
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
soc: rockchip: Fix refcount leak in rockchip_grf_init
of_find_matching_node_and_match returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-49382
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
driver: base: fix UAF when driver_attach failed
When driver_attach(drv); failed, the driver_private will be freed.
But it has been added to the bus, which caused a UAF.
To fix it, we need to delete it from the bus when failed.
CVE-2022-49385
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ubi: ubi_create_volume: Fix use-after-free when volume creation failed
There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s
error handling path:
ubi_eba_replace_table(vol, eba_tbl)
vol->eba_tbl = tbl
out_mapping:
ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'
out_unlock:
put_device(&vol->dev)
vol_release
kfree(tbl->entries) // UAF
Fix it by removing redundant 'eba_tbl' releasing.
Fetch a reproducer in [Link].
CVE-2022-49388
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: usbip: fix a refcount leak in stub_probe()
usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails
after that, usb_put_dev() needs to be called to release the reference.
Fix this by moving usb_put_dev() to sdev_free error path handling.
Find this by code review.
CVE-2022-49389
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can
not ensure that real_dev is freed after macsec. That will trigger the
UAF bug for real_dev as following:
==================================================================
BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
Call Trace:
...
macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
dev_get_iflink+0x73/0xe0 net/core/dev.c:637
default_operstate net/core/link_watch.c:42 [inline]
rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54
linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209:
...
alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549
rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235
veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8:
...
kfree+0xd6/0x4d0 mm/slub.c:4552
kvfree+0x42/0x50 mm/util.c:615
device_release+0x9f/0x240 drivers/base/core.c:2229
kobject_cleanup lib/kobject.c:673 [inline]
kobject_release lib/kobject.c:704 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x1c8/0x540 lib/kobject.c:721
netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")
and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we
can add dev_hold_track() in macsec_dev_init() and dev_put_track() in
macsec_free_netdev() to fix the problem.
CVE-2022-49390
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
um: Fix out-of-bounds read in LDT setup
syscall_stub_data() expects the data_count parameter to be the number of
longs, not bytes.
==================================================================
BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0
Read of size 128 at addr 000000006411f6f0 by task swapper/1
CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18
Call Trace:
show_stack.cold+0x166/0x2a7
__dump_stack+0x3a/0x43
dump_stack_lvl+0x1f/0x27
print_report.cold+0xdb/0xf81
kasan_report+0x119/0x1f0
kasan_check_range+0x3a3/0x440
memcpy+0x52/0x140
syscall_stub_data+0x70/0xe0
write_ldt_entry+0xac/0x190
init_new_ldt+0x515/0x960
init_new_context+0x2c4/0x4d0
mm_init.constprop.0+0x5ed/0x760
mm_alloc+0x118/0x170
0x60033f48
do_one_initcall+0x1d7/0x860
0x60003e7b
kernel_init+0x6e/0x3d4
new_thread_handler+0x1e7/0x2c0
The buggy address belongs to stack of task swapper/1
and is located at offset 64 in frame:
init_new_ldt+0x0/0x960
This frame has 2 objects:
[32, 40) 'addr'
[64, 80) 'desc'
==================================================================
CVE-2022-49395
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom-qmp: fix reset-controller leak on probe errors
Make sure to release the lane reset controller in case of a late probe
error (e.g. probe deferral).
Note that due to the reset controller being defined in devicetree in
"lane" child nodes, devm_reset_control_get_exclusive() cannot be used
directly.
CVE-2022-49396
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom-qmp: fix struct clk leak on probe errors
Make sure to release the pipe clock reference in case of a late probe
error (e.g. probe deferral).
CVE-2022-49397
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Fix potential integer multiplication overflow errors
When multiplying of different types, an overflow is possible even when
storing the result in a larger type. This is because the conversion is
done after the multiplication. So arithmetic overflow and thus in
incorrect value is possible.
Correct an instance of this in the inter packet delay calculation. Fix by
ensuring one of the operands is u64 which will promote the other to u64 as
well ensuring no overflow.
CVE-2022-49404
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix plock invalid read
This patch fixes an invalid read showed by KASAN. A unlock will allocate a
"struct plock_op" and a followed send_op() will append it to a global
send_list data structure. In some cases a followed dev_read() moves it
to recv_list and dev_write() will cast it to "struct plock_xop" and access
fields which are only available in those structures. At this point an
invalid read happens by accessing those fields.
To fix this issue the "callback" field is moved to "struct plock_op" to
indicate that a cast to "plock_xop" is allowed and does the additional
"plock_xop" handling if set.
Example of the KASAN output which showed the invalid read:
[ 2064.296453] ==================================================================
[ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm]
[ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484
[ 2064.308168]
[ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9
[ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 2064.311618] Call Trace:
[ 2064.312218] dump_stack_lvl+0x56/0x7b
[ 2064.313150] print_address_description.constprop.8+0x21/0x150
[ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm]
[ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm]
[ 2064.316595] kasan_report.cold.14+0x7f/0x11b
[ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm]
[ 2064.318687] dev_write+0x52b/0x5a0 [dlm]
[ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm]
[ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10
[ 2064.321926] vfs_write+0x17e/0x930
[ 2064.322769] ? __fget_light+0x1aa/0x220
[ 2064.323753] ksys_write+0xf1/0x1c0
[ 2064.324548] ? __ia32_sys_read+0xb0/0xb0
[ 2064.325464] do_syscall_64+0x3a/0x80
[ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 2064.327606] RIP: 0033:0x7f807e4ba96f
[ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48
[ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f
[ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010
[ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001
[ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80
[ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001
[ 2064.342857]
[ 2064.343226] Allocated by task 12438:
[ 2064.344057] kasan_save_stack+0x1c/0x40
[ 2064.345079] __kasan_kmalloc+0x84/0xa0
[ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220
[ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm]
[ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0
[ 2064.351070] fcntl_setlk+0x281/0xbc0
[ 2064.352879] do_fcntl+0x5e4/0xfe0
[ 2064.354657] __x64_sys_fcntl+0x11f/0x170
[ 2064.356550] do_syscall_64+0x3a/0x80
[ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 2064.360745]
[ 2064.361511] Last potentially related work creation:
[ 2064.363957] kasan_save_stack+0x1c/0x40
[ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0
[ 2064.368100] call_rcu+0x11b/0xf70
[ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm]
[ 2064.372404] receive_from_sock+0x290/0x770 [dlm]
[ 2064.374607] process_recv_sockets+0x32/0x40 [dlm]
[ 2064.377290] process_one_work+0x9a8/0x16e0
[ 2064.379357] worker_thread+0x87/0xbf0
[ 2064.381188] kthread+0x3ac/0x490
[ 2064.383460] ret_from_fork+0x22/0x30
[ 2064.385588]
[ 2064.386518] Second to last potentially related work creation:
[ 2064.389219] kasan_save_stack+0x1c/0x40
[ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0
[ 2064.393303] call_rcu+0x11b/0xf70
[ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm]
[ 2064.397694] receive_from_sock+0x290/0x770
---truncated---
CVE-2022-49407
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on in __es_tree_search
Hulk Robot reported a BUG_ON:
==================================================================
kernel BUG at fs/ext4/extents_status.c:199!
[...]
RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline]
RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217
[...]
Call Trace:
ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766
ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561
ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964
ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384
ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567
ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980
ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031
ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257
v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63
v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82
vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368
dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490
ext4_quota_enable fs/ext4/super.c:6137 [inline]
ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163
ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754
mount_bdev+0x2e9/0x3b0 fs/super.c:1158
mount_fs+0x4b/0x1e4 fs/super.c:1261
[...]
==================================================================
Above issue may happen as follows:
-------------------------------------
ext4_fill_super
ext4_enable_quotas
ext4_quota_enable
ext4_iget
__ext4_iget
ext4_ext_check_inode
ext4_ext_check
__ext4_ext_check
ext4_valid_extent_entries
Check for overlapping extents does't take effect
dquot_enable
vfs_load_quota_inode
v2_check_quota_file
v2_read_header
ext4_quota_read
ext4_bread
ext4_getblk
ext4_map_blocks
ext4_ext_map_blocks
ext4_find_extent
ext4_cache_extents
ext4_es_cache_extent
ext4_es_cache_extent
__es_tree_search
ext4_es_end
BUG_ON(es->es_lblk + es->es_len < es->es_lblk)
The error ext4 extents is as follows:
0af3 0300 0400 0000 00000000 extent_header
00000000 0100 0000 12000000 extent1
00000000 0100 0000 18000000 extent2
02000000 0400 0000 14000000 extent3
In the ext4_valid_extent_entries function,
if prev is 0, no error is returned even if lblock<=prev.
This was intended to skip the check on the first extent, but
in the error image above, prev=0+1-1=0 when checking the second extent,
so even though lblock<=prev, the function does not return an error.
As a result, bug_ON occurs in __es_tree_search and the system panics.
To solve this problem, we only need to check that:
1. The lblock of the first extent is not less than 0.
2. The lblock of the next extent is not less than
the next block of the previous extent.
The same applies to extent_idx.
CVE-2022-49409
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bfq: Make sure bfqg for which we are queueing requests is online
Bios queued into BFQ IO scheduler can be associated with a cgroup that
was already offlined. This may then cause insertion of this bfq_group
into a service tree. But this bfq_group will get freed as soon as last
bio associated with it is completed leading to use after free issues for
service tree users. Fix the problem by making sure we always operate on
online bfq_group. If the bfq_group associated with the bio is not
online, we pick the first online parent.
CVE-2022-49411
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bfq: Update cgroup information before merging bio
When the process is migrated to a different cgroup (or in case of
writeback just starts submitting bios associated with a different
cgroup) bfq_merge_bio() can operate with stale cgroup information in
bic. Thus the bio can be merged to a request from a different cgroup or
it can result in merging of bfqqs for different cgroups or bfqqs of
already dead cgroups and causing possible use-after-free issues. Fix the
problem by updating cgroup information in bfq_merge_bio().
CVE-2022-49413
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix race condition between ext4_write and ext4_convert_inline_data
Hulk Robot reported a BUG_ON:
==================================================================
EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0,
block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters
kernel BUG at fs/ext4/ext4_jbd2.c:53!
invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1
RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline]
RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116
[...]
Call Trace:
ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795
generic_perform_write+0x279/0x3c0 mm/filemap.c:3344
ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270
ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520
do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732
do_iter_write+0x107/0x430 fs/read_write.c:861
vfs_writev fs/read_write.c:934 [inline]
do_pwritev+0x1e5/0x380 fs/read_write.c:1031
[...]
==================================================================
Above issue may happen as follows:
cpu1 cpu2
__________________________|__________________________
do_pwritev
vfs_writev
do_iter_write
ext4_file_write_iter
ext4_buffered_write_iter
generic_perform_write
ext4_da_write_begin
vfs_fallocate
ext4_fallocate
ext4_convert_inline_data
ext4_convert_inline_data_nolock
ext4_destroy_inline_data_nolock
clear EXT4_STATE_MAY_INLINE_DATA
ext4_map_blocks
ext4_ext_map_blocks
ext4_mb_new_blocks
ext4_mb_regular_allocator
ext4_mb_good_group_nolock
ext4_mb_init_group
ext4_mb_init_cache
ext4_mb_generate_buddy --> error
ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)
ext4_restore_inline_data
set EXT4_STATE_MAY_INLINE_DATA
ext4_block_write_begin
ext4_da_write_end
ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)
ext4_write_inline_data_end
handle=NULL
ext4_journal_stop(handle)
__ext4_journal_stop
ext4_put_nojournal(handle)
ref_cnt = (unsigned long)handle
BUG_ON(ref_cnt == 0) ---> BUG_ON
The lock held by ext4_convert_inline_data is xattr_sem, but the lock
held by generic_perform_write is i_rwsem. Therefore, the two locks can
be concurrent.
To solve above issue, we add inode_lock() for ext4_convert_inline_data().
At the same time, move ext4_convert_inline_data() in front of
ext4_punch_hole(), remove similar handling from ext4_punch_hole().
CVE-2022-49414
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix use-after-free in chanctx code
In ieee80211_vif_use_reserved_context(), when we have an
old context and the new context's replace_state is set to
IEEE80211_CHANCTX_REPLACE_NONE, we free the old context
in ieee80211_vif_use_reserved_reassign(). Therefore, we
cannot check the old_ctx anymore, so we should set it to
NULL after this point.
However, since the new_ctx replace state is clearly not
IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do
anything else in this function and can just return to
avoid accessing the freed old_ctx.
CVE-2022-49416
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: annotate races around sk->sk_bound_dev_if
UDP sendmsg() is lockless, and reads sk->sk_bound_dev_if while
this field can be changed by another thread.
Adds minimal annotations to avoid KCSAN splats for UDP.
Following patches will add more annotations to potential lockless readers.
BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg
write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0:
__ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221
ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272
inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576
__sys_connect_file net/socket.c:1900 [inline]
__sys_connect+0x197/0x1b0 net/socket.c:1917
__do_sys_connect net/socket.c:1927 [inline]
__se_sys_connect net/socket.c:1924 [inline]
__x64_sys_connect+0x3d/0x50 net/socket.c:1924
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1:
udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436
inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652
sock_sendmsg_nosec net/socket.c:705 [inline]
sock_sendmsg net/socket.c:725 [inline]
____sys_sendmsg+0x39a/0x510 net/socket.c:2413
___sys_sendmsg net/socket.c:2467 [inline]
__sys_sendmmsg+0x267/0x4c0 net/socket.c:2553
__do_sys_sendmmsg net/socket.c:2582 [inline]
__se_sys_sendmmsg net/socket.c:2579 [inline]
__x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x00000000 -> 0xffffff9b
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
I chose to not add Fixes: tag because race has minor consequences
and stable teams busy enough.
CVE-2022-49420
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup
of_parse_phandle() returns a node pointer with refcount incremented, we should
use of_node_put() on it when not need anymore. Add missing of_node_put() to
avoid refcount leak.
CVE-2022-49421
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Prevent panic when SDMA is disabled
If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to
hfi1_write_iter() will dereference a NULL pointer and panic. A typical
stack frame is:
sdma_select_user_engine [hfi1]
hfi1_user_sdma_process_request [hfi1]
hfi1_write_iter [hfi1]
do_iter_readv_writev
do_iter_write
vfs_writev
do_writev
do_syscall_64
The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with
EINVAL.
CVE-2022-49429
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xics: fix refcount leak in icp_opal_init()
The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.
CVE-2022-49432
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Prevent use of lock before it is initialized
If there is a failure during probe of hfi1 before the sdma_map_lock is
initialized, the call to hfi1_free_devdata() will attempt to use a lock
that has not been initialized. If the locking correctness validator is on
then an INFO message and stack trace resembling the following may be seen:
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
Call Trace:
register_lock_class+0x11b/0x880
__lock_acquire+0xf3/0x7930
lock_acquire+0xff/0x2d0
_raw_spin_lock_irq+0x46/0x60
sdma_clean+0x42a/0x660 [hfi1]
hfi1_free_devdata+0x3a7/0x420 [hfi1]
init_one+0x867/0x11a0 [hfi1]
pci_device_probe+0x40e/0x8d0
The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map
memory, and sdma_map is not allocated/initialized until after
sdma_map_lock has been initialized. This code only needs to be run if
sdma_map is not NULL, and so checking for that condition will avoid trying
to use the lock before it is initialized.
CVE-2022-49433
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()
The sysfs sriov_numvfs_store() path acquires the device lock before the
config space access lock:
sriov_numvfs_store
device_lock # A (1) acquire device lock
sriov_configure
vfio_pci_sriov_configure # (for example)
vfio_pci_core_sriov_configure
pci_disable_sriov
sriov_disable
pci_cfg_access_lock
pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0
Previously, pci_dev_lock() acquired the config space access lock before the
device lock:
pci_dev_lock
pci_cfg_access_lock
dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1
device_lock # A (3) wait for device lock
Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may
deadlock with sriov_numvfs_store() if the operations occur in the sequence
(1) (2) (3) (4).
Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires
the device lock before the config space access lock, the same as the
sriov_numvfs_store() path.
[bhelgaas: combined and adapted commit log from Jay Zhou's independent
subsequent posting:
https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
CVE-2022-49434
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive: Fix refcount leak in xive_spapr_init
of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-49437
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: fix deadlock caused by calling printk() under tty_port->lock
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda842fe96 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty #10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> #1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773
---truncated---
CVE-2022-49441
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers/base/node.c: fix compaction sysfs file leak
Compaction sysfs file is created via compaction_register_node in
register_node. But we forgot to remove it in unregister_node. Thus
compaction sysfs file is leaked. Using compaction_unregister_node to fix
this issue.
CVE-2022-49442
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist
ep_poll() first calls ep_events_available() with no lock held and checks
if ep->rdllist is empty by list_empty_careful(), which reads
rdllist->prev. Thus all accesses to it need some protection to avoid
store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev
and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket
fds.") added the first lockless ep_events_available(), and commit
c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()")
made some ep_events_available() calls lockless and added single call under
a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock
for zero timeout") made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:
INIT_LIST_HEAD include/linux/list.h:38 [inline]
list_splice_init include/linux/list.h:492 [inline]
ep_start_scan fs/eventpoll.c:622 [inline]
ep_send_events fs/eventpoll.c:1656 [inline]
ep_poll fs/eventpoll.c:1806 [inline]
do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234
do_epoll_pwait fs/eventpoll.c:2268 [inline]
__do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]
__se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275
__x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:
list_empty_careful include/linux/list.h:329 [inline]
ep_events_available fs/eventpoll.c:381 [inline]
ep_poll fs/eventpoll.c:1797 [inline]
do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234
do_epoll_pwait fs/eventpoll.c:2268 [inline]
__do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]
__se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275
__x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
CVE-2022-49443
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
module: fix [e_shstrndx].sh_size=0 OOB access
It is trivial to craft a module to trigger OOB access in this line:
if (info->secstrings[strhdr->sh_size - 1] != '\0') {
BUG: unable to handle page fault for address: ffffc90000aa0fff
PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
RIP: 0010:load_module+0x19b/0x2391
[rebased patch onto modules-next]
CVE-2022-49444
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.
CVE-2022-49445
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: rk3399_dmc: Disable edev on remove()
Otherwise we hit an unablanced enable-count when unbinding the DFI
device:
[ 1279.659119] ------------[ cut here ]------------
[ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c
...
[ 1279.659352] Hardware name: Google Kevin (DT)
[ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
[ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c
[ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28
...
[ 1279.659571] Call trace:
[ 1279.659582] devfreq_event_remove_edev+0x84/0x8c
[ 1279.659590] devm_devfreq_event_release+0x1c/0x28
[ 1279.659602] release_nodes+0x1cc/0x244
[ 1279.659611] devres_release_all+0x44/0x60
[ 1279.659621] device_release_driver_internal+0x11c/0x1ac
[ 1279.659629] device_driver_detach+0x20/0x2c
[ 1279.659641] unbind_store+0x7c/0xb0
[ 1279.659650] drv_attr_store+0x2c/0x40
[ 1279.659663] sysfs_kf_write+0x44/0x58
[ 1279.659672] kernfs_fop_write_iter+0xf4/0x190
[ 1279.659684] vfs_write+0x2b0/0x2e4
[ 1279.659693] ksys_write+0x80/0xec
[ 1279.659701] __arm64_sys_write+0x24/0x30
[ 1279.659714] el0_svc_common+0xf0/0x1d8
[ 1279.659724] do_el0_svc_compat+0x28/0x3c
[ 1279.659738] el0_svc_compat+0x10/0x1c
[ 1279.659746] el0_sync_compat_handler+0xa8/0xcc
[ 1279.659758] el0_sync_compat+0x188/0x1c0
[ 1279.659768] ---[ end trace cec200e5094155b4 ]---
CVE-2022-49460
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
blk-throttle: Set BIO_THROTTLED when bio has been throttled
1.In current process, all bio will set the BIO_THROTTLED flag
after __blk_throtl_bio().
2.If bio needs to be throttled, it will start the timer and
stop submit bio directly. Bio will submit in
blk_throtl_dispatch_work_fn() when the timer expires.But in
the current process, if bio is throttled. The BIO_THROTTLED
will be set to bio after timer start. If the bio has been
completed, it may cause use-after-free blow.
BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70
Read of size 2 at addr ffff88801b8902d4 by task fio/26380
dump_stack+0x9b/0xce
print_address_description.constprop.6+0x3e/0x60
kasan_report.cold.9+0x22/0x3a
blk_throtl_bio+0x12f0/0x2c70
submit_bio_checks+0x701/0x1550
submit_bio_noacct+0x83/0xc80
submit_bio+0xa7/0x330
mpage_readahead+0x380/0x500
read_pages+0x1c1/0xbf0
page_cache_ra_unbounded+0x471/0x6f0
do_page_cache_ra+0xda/0x110
ondemand_readahead+0x442/0xae0
page_cache_async_ra+0x210/0x300
generic_file_buffered_read+0x4d9/0x2130
generic_file_read_iter+0x315/0x490
blkdev_read_iter+0x113/0x1b0
aio_read+0x2ad/0x450
io_submit_one+0xc8e/0x1d60
__se_sys_io_submit+0x125/0x350
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Allocated by task 26380:
kasan_save_stack+0x19/0x40
__kasan_kmalloc.constprop.2+0xc1/0xd0
kmem_cache_alloc+0x146/0x440
mempool_alloc+0x125/0x2f0
bio_alloc_bioset+0x353/0x590
mpage_alloc+0x3b/0x240
do_mpage_readpage+0xddf/0x1ef0
mpage_readahead+0x264/0x500
read_pages+0x1c1/0xbf0
page_cache_ra_unbounded+0x471/0x6f0
do_page_cache_ra+0xda/0x110
ondemand_readahead+0x442/0xae0
page_cache_async_ra+0x210/0x300
generic_file_buffered_read+0x4d9/0x2130
generic_file_read_iter+0x315/0x490
blkdev_read_iter+0x113/0x1b0
aio_read+0x2ad/0x450
io_submit_one+0xc8e/0x1d60
__se_sys_io_submit+0x125/0x350
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 0:
kasan_save_stack+0x19/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x1b/0x30
__kasan_slab_free+0x111/0x160
kmem_cache_free+0x94/0x460
mempool_free+0xd6/0x320
bio_free+0xe0/0x130
bio_put+0xab/0xe0
bio_endio+0x3a6/0x5d0
blk_update_request+0x590/0x1370
scsi_end_request+0x7d/0x400
scsi_io_completion+0x1aa/0xe50
scsi_softirq_done+0x11b/0x240
blk_mq_complete_request+0xd4/0x120
scsi_mq_done+0xf0/0x200
virtscsi_vq_done+0xbc/0x150
vring_interrupt+0x179/0x390
__handle_irq_event_percpu+0xf7/0x490
handle_irq_event_percpu+0x7b/0x160
handle_irq_event+0xcc/0x170
handle_edge_irq+0x215/0xb20
common_interrupt+0x60/0x120
asm_common_interrupt+0x1e/0x40
Fix this by move BIO_THROTTLED set into the queue_lock.
CVE-2022-49465
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm: msm: fix possible memory leak in mdp5_crtc_cursor_set()
drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo
needs to be put when msm_gem_get_and_pin_iova fails.
CVE-2022-49467
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: phy: micrel: Allow probing without .driver_data
Currently, if the .probe element is present in the phy_driver structure
and the .driver_data is not, a NULL pointer dereference happens.
Allow passing .probe without .driver_data by inserting NULL checks
for priv->type.
CVE-2022-49472
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout
Connecting the same socket twice consecutively in sco_sock_connect()
could lead to a race condition where two sco_conn objects are created
but only one is associated with the socket. If the socket is closed
before the SCO connection is established, the timer associated with the
dangling sco_conn object won't be canceled. As the sock object is being
freed, the use-after-free problem happens when the timer callback
function sco_sock_timeout() accesses the socket. Here's the call trace:
dump_stack+0x107/0x163
? refcount_inc+0x1c/
print_address_description.constprop.0+0x1c/0x47e
? refcount_inc+0x1c/0x7b
kasan_report+0x13a/0x173
? refcount_inc+0x1c/0x7b
check_memory_region+0x132/0x139
refcount_inc+0x1c/0x7b
sco_sock_timeout+0xb2/0x1ba
process_one_work+0x739/0xbd1
? cancel_delayed_work+0x13f/0x13f
? __raw_spin_lock_init+0xf0/0xf0
? to_kthread+0x59/0x85
worker_thread+0x593/0x70e
kthread+0x346/0x35a
? drain_workqueue+0x31a/0x31a
? kthread_bind+0x4b/0x4b
ret_from_fork+0x1f/0x30
CVE-2022-49474
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init
Syzbot reported that -1 is used as array index. The problem was in
missing validation check.
hdw->unit_number is initialized with -1 and then if init table walk fails
this value remains unchanged. Since code blindly uses this member for
array indexing adding sanity check is the easiest fix for that.
hdw->workpoll initialization moved upper to prevent warning in
__flush_work.
CVE-2022-49478
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected
There is a possibility for mdp5_get_global_state to return
-EDEADLK when acquiring the modeset lock, but currently global_state in
mdp5_mixer_release doesn't check for if an error is returned.
To avoid a NULL dereference error, let's have mdp5_mixer_release
check if an error is returned and propagate that error.
Patchwork: https://patchwork.freedesktop.org/patch/485181/
CVE-2022-49488
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume
BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3
Call trace:
dpu_vbif_init_memtypes+0x40/0xb8
dpu_runtime_resume+0xcc/0x1c0
pm_generic_runtime_resume+0x30/0x44
__genpd_runtime_resume+0x68/0x7c
genpd_runtime_resume+0x134/0x258
__rpm_callback+0x98/0x138
rpm_callback+0x30/0x88
rpm_resume+0x36c/0x49c
__pm_runtime_resume+0x80/0xb0
dpu_core_irq_uninstall+0x30/0xb0
dpu_irq_uninstall+0x18/0x24
msm_drm_uninit+0xd8/0x16c
Patchwork: https://patchwork.freedesktop.org/patch/483255/
[DB: fixed Fixes tag]
CVE-2022-49489
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()
It will cause null-ptr-deref in resource_size(), if platform_get_resource()
returns NULL, move calling resource_size() after devm_ioremap_resource() that
will check 'res' to avoid null-ptr-deref.
CVE-2022-49491
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags
In nvme_alloc_admin_tags, the admin_q can be set to an error (typically
-ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which
is checked immediately after the call. However, when we return the error
message up the stack, to nvme_reset_work the error takes us to
nvme_remove_dead_ctrl()
nvme_dev_disable()
nvme_suspend_queue(&dev->queues[0]).
Here, we only check that the admin_q is non-NULL, rather than not
an error or NULL, and begin quiescing a queue that never existed, leading
to bad / NULL pointer dereference.
CVE-2022-49492
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/hdmi: check return value after calling platform_get_resource_byname()
It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
we need check the return value.
Patchwork: https://patchwork.freedesktop.org/patch/482992/
CVE-2022-49495
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: remove two BUG() from skb_checksum_help()
I have a syzbot report that managed to get a crash in skb_checksum_help()
If syzbot can trigger these BUG(), it makes sense to replace
them with more friendly WARN_ON_ONCE() since skb_checksum_help()
can instead return an error code.
Note that syzbot will still crash there, until real bug is fixed.
CVE-2022-49497
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix
The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to
ensure that it is within the bitmap.
drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept()
error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()'
CVE-2022-49503
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Inhibit aborts if external loopback plug is inserted
After running a short external loopback test, when the external loopback is
removed and a normal cable inserted that is directly connected to a target
device, the system oops in the llpfc_set_rrq_active() routine.
When the loopback was inserted an FLOGI was transmit. As we're looped back,
we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same
wppn thus understand it's a loopback. However, as the ABTS sends address
information the port is not set to (fffffe), the ABTS is dropped on the
wire. A short 1 frame loopback test is run and completes before the ABTS
times out. The looback is unplugged and the new cable plugged in, and the
an FLOGI to the new device occurs and completes. Due to a mixup in ref
counting the completion of the new FLOGI releases the fabric ndlp. Then the
original ABTS completes and references the released ndlp generating the
oops.
Correct by no-op'ing the ABTS when in loopback mode (it will be dropped
anyway). Added a flag to track the mode to recognize when it should be
no-op'd.
CVE-2022-49504
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFC: NULL out the dev->rfkill to prevent UAF
Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
assumes the device_is_registered() in function nfc_dev_up() will help
to check when the rfkill is unregistered. However, this check only
take effect when device_del(&dev->dev) is done in nfc_unregister_device().
Hence, the rfkill object is still possible be dereferenced.
The crash trace in latest kernel (5.18-rc2):
[ 68.760105] ==================================================================
[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750
[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313
[ 68.760756]
[ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4
[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 68.760756] Call Trace:
[ 68.760756] <TASK>
[ 68.760756] dump_stack_lvl+0x57/0x7d
[ 68.760756] print_report.cold+0x5e/0x5db
[ 68.760756] ? __lock_acquire+0x3ec1/0x6750
[ 68.760756] kasan_report+0xbe/0x1c0
[ 68.760756] ? __lock_acquire+0x3ec1/0x6750
[ 68.760756] __lock_acquire+0x3ec1/0x6750
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] ? register_lock_class+0x18d0/0x18d0
[ 68.760756] lock_acquire+0x1ac/0x4f0
[ 68.760756] ? rfkill_blocked+0xe/0x60
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0
[ 68.760756] ? nla_get_range_signed+0x540/0x540
[ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50
[ 68.760756] _raw_spin_lock_irqsave+0x39/0x50
[ 68.760756] ? rfkill_blocked+0xe/0x60
[ 68.760756] rfkill_blocked+0xe/0x60
[ 68.760756] nfc_dev_up+0x84/0x260
[ 68.760756] nfc_genl_dev_up+0x90/0xe0
[ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0
[ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230
[ 68.760756] ? security_capable+0x51/0x90
[ 68.760756] genl_rcv_msg+0x280/0x500
[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0
[ 68.760756] ? lock_acquire+0x1ac/0x4f0
[ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0
[ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 68.760756] netlink_rcv_skb+0x11b/0x340
[ 68.760756] ? genl_get_cmd+0x3c0/0x3c0
[ 68.760756] ? netlink_ack+0x9c0/0x9c0
[ 68.760756] ? netlink_deliver_tap+0x136/0xb00
[ 68.760756] genl_rcv+0x1f/0x30
[ 68.760756] netlink_unicast+0x430/0x710
[ 68.760756] ? memset+0x20/0x40
[ 68.760756] ? netlink_attachskb+0x740/0x740
[ 68.760756] ? __build_skb_around+0x1f4/0x2a0
[ 68.760756] netlink_sendmsg+0x75d/0xc00
[ 68.760756] ? netlink_unicast+0x710/0x710
[ 68.760756] ? netlink_unicast+0x710/0x710
[ 68.760756] sock_sendmsg+0xdf/0x110
[ 68.760756] __sys_sendto+0x19e/0x270
[ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0
[ 68.760756] ? fd_install+0x178/0x4c0
[ 68.760756] ? fd_install+0x195/0x4c0
[ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0
[ 68.760756] __x64_sys_sendto+0xd8/0x1b0
[ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130
[ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50
[ 68.760756] do_syscall_64+0x3b/0x90
[ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 68.760756] RIP: 0033:0x7f67fb50e6b3
...
[ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
[ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3
[ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003
[ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c
[ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e
[ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003
[ 68.760756] </TASK>
[ 68.760756]
[ 68.760756] Allocated by task 279:
[ 68.760756] kasan_save_stack+0x1e/0x40
[
---truncated---
CVE-2022-49505
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and
the struct gov_attr_set embeds a kobject. Since every kobject must have
a release() method and we can't use kfree() to free it directly,
so introduce cpufreq_dbs_data_release() to release the dbs_data via
the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34
WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
Modules linked in:
CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536
Hardware name: Marvell OcteonTX CN96XX board (DT)
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : debug_print_object+0xb8/0x100
lr : debug_print_object+0xb8/0x100
sp : ffff80001dfcf9a0
x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000
x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210
x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118
x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000
x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8
x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14
x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0
x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001
x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040
Call trace:
debug_print_object+0xb8/0x100
__debug_check_no_obj_freed+0x1d0/0x25c
debug_check_no_obj_freed+0x24/0xa0
kfree+0x11c/0x440
cpufreq_dbs_governor_exit+0xa8/0xac
cpufreq_exit_governor+0x44/0x90
cpufreq_set_policy+0x29c/0x570
store_scaling_governor+0x110/0x154
store+0xb0/0xe0
sysfs_kf_write+0x58/0x84
kernfs_fop_write_iter+0x12c/0x1c0
new_sync_write+0xf0/0x18c
vfs_write+0x1cc/0x220
ksys_write+0x74/0x100
__arm64_sys_write+0x28/0x3c
invoke_syscall.constprop.0+0x58/0xf0
do_el0_svc+0x70/0x170
el0_svc+0x54/0x190
el0t_64_sync_handler+0xa4/0x130
el0t_64_sync+0x1a0/0x1a4
irq event stamp: 189006
hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0
hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0
softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0
softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
[ rjw: Because can be freed by the gov_attr_set_put() in
cpufreq_dbs_governor_exit() now, it is also necessary to put the
invocation of the governor ->exit() callback into the new
cpufreq_dbs_data_release() function. ]
CVE-2022-49513
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ice: always check VF VSI pointer values
The ice_get_vf_vsi function can return NULL in some cases, such as if
handling messages during a reset where the VSI is being removed and
recreated.
Several places throughout the driver do not bother to check whether this
VSI pointer is valid. Static analysis tools maybe report issues because
they detect paths where a potentially NULL pointer could be dereferenced.
Fix this by checking the return value of ice_get_vf_vsi everywhere.
CVE-2022-49516
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ath10k: skip ath10k_halt during suspend for driver state RESTARTING
Double free crash is observed when FW recovery(caused by wmi
timeout/crash) is followed by immediate suspend event. The FW recovery
is triggered by ath10k_core_restart() which calls driver clean up via
ath10k_halt(). When the suspend event occurs between the FW recovery,
the restart worker thread is put into frozen state until suspend completes.
The suspend event triggers ath10k_stop() which again triggers ath10k_halt()
The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be
called twice(Note: ath10k_htt_rx_alloc was not called by restart worker
thread because of its frozen state), causing the crash.
To fix this, during the suspend flow, skip call to ath10k_halt() in
ath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING.
Also, for driver state ATH10K_STATE_RESTARTING, call
ath10k_wait_for_suspend() in ath10k_stop(). This is because call to
ath10k_wait_for_suspend() is skipped later in
[ath10k_halt() > ath10k_core_stop()] for the driver state
ATH10K_STATE_RESTARTING.
The frozen restart worker thread will be cancelled during resume when the
device comes out of suspend.
Below is the crash stack for reference:
[ 428.469167] ------------[ cut here ]------------
[ 428.469180] kernel BUG at mm/slub.c:4150!
[ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 428.469219] Workqueue: events_unbound async_run_entry_fn
[ 428.469230] RIP: 0010:kfree+0x319/0x31b
[ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246
[ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000
[ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000
[ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000
[ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 428.469285] Call Trace:
[ 428.469295] ? dma_free_attrs+0x5f/0x7d
[ 428.469320] ath10k_core_stop+0x5b/0x6f
[ 428.469336] ath10k_halt+0x126/0x177
[ 428.469352] ath10k_stop+0x41/0x7e
[ 428.469387] drv_stop+0x88/0x10e
[ 428.469410] __ieee80211_suspend+0x297/0x411
[ 428.469441] rdev_suspend+0x6e/0xd0
[ 428.469462] wiphy_suspend+0xb1/0x105
[ 428.469483] ? name_show+0x2d/0x2d
[ 428.469490] dpm_run_callback+0x8c/0x126
[ 428.469511] ? name_show+0x2d/0x2d
[ 428.469517] __device_suspend+0x2e7/0x41b
[ 428.469523] async_suspend+0x1f/0x93
[ 428.469529] async_run_entry_fn+0x3d/0xd1
[ 428.469535] process_one_work+0x1b1/0x329
[ 428.469541] worker_thread+0x213/0x372
[ 428.469547] kthread+0x150/0x15f
[ 428.469552] ? pr_cont_work+0x58/0x58
[ 428.469558] ? kthread_blkcg+0x31/0x31
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
CVE-2022-49519
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp()
If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a
received frame, the frame is dropped and resources are leaked.
Fix by returning resources when discarding an unhandled frame type. Update
lpfc_fc_frame_check() handling of NOP basic link service.
CVE-2022-49521
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: pci: cx23885: Fix the error handling in cx23885_initdev()
When the driver fails to call the dma_set_mask(), the driver will get
the following splat:
[ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240
[ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590
[ 55.856822] Call Trace:
[ 55.860327] __process_removed_driver+0x3c/0x240
[ 55.861347] bus_for_each_dev+0x102/0x160
[ 55.861681] i2c_del_driver+0x2f/0x50
This is because the driver has initialized the i2c related resources
in cx23885_dev_setup() but not released them in error handling, fix this
bug by modifying the error path that jumps after failing to call the
dma_set_mask().
CVE-2022-49524
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: cx25821: Fix the warning when removing the module
When removing the module, we will get the following warning:
[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'
[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0
[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0
[ 14.759589] Call Trace:
[ 14.759792] <TASK>
[ 14.759975] unregister_irq_proc+0x14c/0x170
[ 14.760340] irq_free_descs+0x94/0xe0
[ 14.760640] mp_unmap_irq+0xb6/0x100
[ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40
[ 14.761334] acpi_pci_irq_disable+0x1d3/0x320
[ 14.761688] pci_disable_device+0x1ad/0x380
[ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60
[ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821]
[ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821]
[ 14.763242] pci_device_remove+0x92/0x240
Fix this by freeing the irq before call pci_disable_device().
CVE-2022-49525
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/bitmap: don't set sb values if can't pass sanity check
If bitmap area contains invalid data, kernel will crash then mdadm
triggers "Segmentation fault".
This is cluster-md speical bug. In non-clustered env, mdadm will
handle broken metadata case. In clustered array, only kernel space
handles bitmap slot info. But even this bug only happened in clustered
env, current sanity check is wrong, the code should be changed.
How to trigger: (faulty injection)
dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda
dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb
mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb
mdadm -Ss
echo aaa > magic.txt
== below modifying slot 2 bitmap data ==
dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic
dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize
mdadm -A /dev/md0 /dev/sda /dev/sdb
== kernel crashes. mdadm outputs "Segmentation fault" ==
Reason of kernel crash:
In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't
block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T()
trigger "divide error".
Crash log:
kernel: md: md0 stopped.
kernel: md/raid1:md0: not clean -- starting background reconstruction
kernel: md/raid1:md0: active with 2 out of 2 mirrors
kernel: dlm: ... ...
kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1
kernel: md0: invalid bitmap file superblock: bad magic
kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2
kernel: md-cluster: Could not gather bitmaps from slot 2
kernel: divide error: 0000 [#1] SMP NOPTI
kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default
kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246
kernel: ... ...
kernel: Call Trace:
kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0]
kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a]
kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0]
kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a]
kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a]
kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a]
kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a]
kernel: ? blkdev_ioctl+0xb1/0x2b0
kernel: block_ioctl+0x3b/0x40
kernel: __x64_sys_ioctl+0x7f/0xb0
kernel: do_syscall_64+0x59/0x80
kernel: ? exit_to_user_mode_prepare+0x1ab/0x230
kernel: ? syscall_exit_to_user_mode+0x18/0x40
kernel: ? do_syscall_64+0x69/0x80
kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae
kernel: RIP: 0033:0x7f4a15fa722b
kernel: ... ...
kernel: ---[ end trace 8afa7612f559c868 ]---
kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
CVE-2022-49526
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix double free in si_parse_power_table()
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
CVE-2022-49530
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
CVE-2022-49532
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT
There is a potential memory leak in lpfc_ignore_els_cmpl() and
lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT
(lpfc_rcv_plogi()'s login_mbox).
Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(),
and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for
service parameters.
For lpfc_els_rsp_reject() failure, free both the ctx_buf for service
parameters and the login_mbox.
CVE-2022-49534
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI
If lpfc_issue_els_flogi() fails and returns non-zero status, the node
reference count is decremented to trigger the release of the nodelist
structure. However, if there is a prior registration or dev-loss-evt work
pending, the node may be released prematurely. When dev-loss-evt
completes, the released node is referenced causing a use-after-free null
pointer dereference.
Similarly, when processing non-zero ELS PLOGI completion status in
lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport
registration before triggering node removal. If dev-loss-evt work is
pending, the node may be released prematurely and a subsequent call to
lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference.
Add test for pending dev-loss before decrementing the node reference count
for FLOGI, PLOGI, PRLI, and ADISC handling.
CVE-2022-49535
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock
During stress I/O tests with 500+ vports, hard LOCKUP call traces are
observed.
CPU A:
native_queued_spin_lock_slowpath+0x192
_raw_spin_lock_irqsave+0x32
lpfc_handle_fcp_err+0x4c6
lpfc_fcp_io_cmd_wqe_cmpl+0x964
lpfc_sli4_fp_handle_cqe+0x266
__lpfc_sli4_process_cq+0x105
__lpfc_sli4_hba_process_cq+0x3c
lpfc_cq_poll_hdler+0x16
irq_poll_softirq+0x76
__softirqentry_text_start+0xe4
irq_exit+0xf7
do_IRQ+0x7f
CPU B:
native_queued_spin_lock_slowpath+0x5b
_raw_spin_lock+0x1c
lpfc_abort_handler+0x13e
scmd_eh_abort_handler+0x85
process_one_work+0x1a7
worker_thread+0x30
kthread+0x112
ret_from_fork+0x1f
Diagram of lockup:
CPUA CPUB
---- ----
lpfc_cmd->buf_lock
phba->hbalock
lpfc_cmd->buf_lock
phba->hbalock
Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in
lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock
first before phba->hbalock.
CVE-2022-49536
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix call trace observed during I/O with CMF enabled
The following was seen with CMF enabled:
BUG: using smp_processor_id() in preemptible
code: systemd-udevd/31711
kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc]
kernel: CPU: 12 PID: 31711 Comm: systemd-udevd
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x44/0x57
kernel: check_preemption_disabled+0xbf/0xe0
kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc]
kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc]
this_cpu_ptr() calls smp_processor_id() in a preemptible context.
Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.
CVE-2022-49537
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: jack: Access input_dev under mutex
It is possible when using ASoC that input_dev is unregistered while
calling snd_jack_report, which causes NULL pointer dereference.
In order to prevent this serialize access to input_dev using mutex lock.
CVE-2022-49538
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()
In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard
lockup call trace hangs the system.
Call Trace:
_raw_spin_lock_irqsave+0x32/0x40
lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc]
lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc]
lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc]
lpfc_els_flush_cmd+0x43c/0x670 [lpfc]
lpfc_els_flush_all_cmd+0x37/0x60 [lpfc]
lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc]
lpfc_do_work+0x1485/0x1d70 [lpfc]
kthread+0x112/0x130
ret_from_fork+0x1f/0x40
Kernel panic - not syncing: Hard LOCKUP
The same CPU tries to claim the phba->port_list_lock twice.
Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and
lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need
to take the phba->port_list_lock within lpfc_dmp_dbg().
CVE-2022-49542
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipw2x00: Fix potential NULL dereference in libipw_xmit()
crypt and crypt->ops could be null, so we need to checking null
before dereference
CVE-2022-49544
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Cancel pending work at closing a MIDI substream
At closing a USB MIDI output substream, there might be still a pending
work, which would eventually access the rawmidi runtime object that is
being released. For fixing the race, make sure to cancel the pending
work at closing.
CVE-2022-49545
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
x86/kexec: fix memory leak of elf header buffer
This is reported by kmemleak detector:
unreferenced object 0xffffc900002a9000 (size 4096):
comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s)
hex dump (first 32 bytes):
7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............
04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>.............
backtrace:
[<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170
[<000000002b66b6c0>] __vmalloc_node+0xb4/0x160
[<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0
[<0000000019afff23>] crash_load_segments+0x260/0x470
[<0000000019ebe95c>] bzImage64_load+0x814/0xad0
[<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0
[<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0
[<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530
[<0000000087c19992>] do_syscall_64+0x3b/0x90
[<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae
In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to
store elf headers. While it's not freed back to system correctly when
kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it
by introducing x86 specific function arch_kimage_file_post_load_cleanup(),
and freeing the buffer there.
And also remove the incorrect elf header buffer freeing code. Before
calling arch specific kexec_file loading function, the image instance has
been initialized. So 'image->elf_headers' must be NULL. It doesn't make
sense to free the elf header buffer in the place.
Three different people have reported three bugs about the memory leak on
x86_64 inside Redhat.
CVE-2022-49546
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: Use del_timer_sync() before freeing
While looking at a crash report on a timer list being corrupted, which
usually happens when a timer is freed while still active. This is
commonly triggered by code calling del_timer() instead of
del_timer_sync() just before freeing.
One possible culprit is the hci_qca driver, which does exactly that.
Eric mentioned that wake_retrans_timer could be rearmed via the work
queue, so also move the destruction of the work queue before
del_timer_sync().
CVE-2022-49555
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: re-fetch conntrack after insertion
In case the conntrack is clashing, insertion can free skb->_nfct and
set skb->_nfct to the already-confirmed entry.
This wasn't found before because the conntrack entry and the extension
space used to free'd after an rcu grace period, plus the race needs
events enabled to trigger.
CVE-2022-49561
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - add param check for RSA
Reject requests with a source buffer that is bigger than the size of the
key. This is to prevent a possible integer underflow that might happen
when copying the source scatterlist into a linear buffer.
CVE-2022-49563
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - add param check for DH
Reject requests with a source buffer that is bigger than the size of the
key. This is to prevent a possible integer underflow that might happen
when copying the source scatterlist into a linear buffer.
CVE-2022-49564
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - fix memory leak in RSA
When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is
used, some components of the private key persist even after the TFM is
released.
Replace the explicit calls to free the buffers in qat_rsa_exit_tfm()
with a call to qat_rsa_clear_ctx() which frees all buffers referenced in
the TFM context.
CVE-2022-49566
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ip: Fix data-races around sysctl_ip_prot_sock.
sysctl_ip_prot_sock is accessed concurrently, and there is always a chance
of data-race. So, all readers and writers need some basic protection to
avoid load/store-tearing.
CVE-2022-49578
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
be2net: Fix buffer overflow in be_get_module_eeprom
be_cmd_read_port_transceiver_data assumes that it is given a buffer that
is at least PAGE_DATA_LEN long, or twice that if the module supports SFF
8472. However, this is not always the case.
Fix this by passing the desired offset and length to
be_cmd_read_port_transceiver_data so that we only copy the bytes once.
CVE-2022-49581
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero
It is possible to disable VFs while the PF driver is processing requests
from the VF driver. This can result in a panic.
BUG: unable to handle kernel paging request at 000000000000106c
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- -
Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020
RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe]
Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff
01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c
00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a
RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002
RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b
RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006
RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780
R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020
R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80
FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<IRQ>
? ttwu_do_wakeup+0x19/0x140
? try_to_wake_up+0x1cd/0x550
? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf]
ixgbe_msix_other+0x17e/0x310 [ixgbe]
__handle_irq_event_percpu+0x40/0x180
handle_irq_event_percpu+0x30/0x80
handle_irq_event+0x36/0x53
handle_edge_irq+0x82/0x190
handle_irq+0x1c/0x30
do_IRQ+0x49/0xd0
common_interrupt+0xf/0xf
This can be eventually be reproduced with the following script:
while :
do
echo 63 > /sys/class/net/<devname>/device/sriov_numvfs
sleep 1
echo 0 > /sys/class/net/<devname>/device/sriov_numvfs
sleep 1
done
Add lock when disabling SR-IOV to prevent process VF mailbox communication.
CVE-2022-49584
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igmp: Fix data-races around sysctl_igmp_qrv.
While reading sysctl_igmp_qrv, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.
This test can be packed into a helper, so such changes will be in the
follow-up series after net is merged into net-next.
qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
CVE-2022-49589
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igmp: Fix data-races around sysctl_igmp_llm_reports.
While reading sysctl_igmp_llm_reports, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.
This test can be packed into a helper, so such changes will be in the
follow-up series after net is merged into net-next.
if (ipv4_is_local_multicast(pmc->multiaddr) &&
!READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))
CVE-2022-49590
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix dma queue left shift overflow issue
When queue number is > 4, left shift overflows due to 32 bits
integer variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1.
If CONFIG_UBSAN is enabled, kernel dumps below warning:
[ 10.363842] ==================================================================
[ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/
linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12
[ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int'
[ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg
[ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021
[ 10.363958] Call Trace:
[ 10.363960] <TASK>
[ 10.363963] dump_stack_lvl+0x4a/0x5f
[ 10.363971] dump_stack+0x10/0x12
[ 10.363974] ubsan_epilogue+0x9/0x45
[ 10.363976] __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
[ 10.363979] ? wake_up_klogd+0x4a/0x50
[ 10.363983] ? vprintk_emit+0x8f/0x240
[ 10.363986] dwmac4_map_mtl_dma.cold+0x42/0x91 [stmmac]
[ 10.364001] stmmac_mtl_configuration+0x1ce/0x7a0 [stmmac]
[ 10.364009] ? dwmac410_dma_init_channel+0x70/0x70 [stmmac]
[ 10.364020] stmmac_hw_setup.cold+0xf/0xb14 [stmmac]
[ 10.364030] ? page_pool_alloc_pages+0x4d/0x70
[ 10.364034] ? stmmac_clear_tx_descriptors+0x6e/0xe0 [stmmac]
[ 10.364042] stmmac_open+0x39e/0x920 [stmmac]
[ 10.364050] __dev_open+0xf0/0x1a0
[ 10.364054] __dev_change_flags+0x188/0x1f0
[ 10.364057] dev_change_flags+0x26/0x60
[ 10.364059] do_setlink+0x908/0xc40
[ 10.364062] ? do_setlink+0xb10/0xc40
[ 10.364064] ? __nla_validate_parse+0x4c/0x1a0
[ 10.364068] __rtnl_newlink+0x597/0xa10
[ 10.364072] ? __nla_reserve+0x41/0x50
[ 10.364074] ? __kmalloc_node_track_caller+0x1d0/0x4d0
[ 10.364079] ? pskb_expand_head+0x75/0x310
[ 10.364082] ? nla_reserve_64bit+0x21/0x40
[ 10.364086] ? skb_free_head+0x65/0x80
[ 10.364089] ? security_sock_rcv_skb+0x2c/0x50
[ 10.364094] ? __cond_resched+0x19/0x30
[ 10.364097] ? kmem_cache_alloc_trace+0x15a/0x420
[ 10.364100] rtnl_newlink+0x49/0x70
This change fixes MTL_RXQ_DMA_MAP1 mask issue and channel/queue
mapping warning.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216195
CVE-2022-49592
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igc: Reinstate IGC_REMOVED logic and implement it properly
The initially merged version of the igc driver code (via commit
146740f9abc4, "igc: Add support for PF") contained the following
IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors:
u32 igc_rd32(struct igc_hw *hw, u32 reg)
{
u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
u32 value = 0;
if (IGC_REMOVED(hw_addr))
return ~value;
value = readl(&hw_addr[reg]);
/* reads should not return all F's */
if (!(~value) && (!reg || !(~readl(hw_addr))))
hw->hw_addr = NULL;
return value;
}
And:
#define wr32(reg, val) \
do { \
u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \
if (!IGC_REMOVED(hw_addr)) \
writel((val), &hw_addr[(reg)]); \
} while (0)
E.g. igb has similar checks in its MMIO accessors, and has a similar
macro E1000_REMOVED, which is implemented as follows:
#define E1000_REMOVED(h) unlikely(!(h))
These checks serve to detect and take note of an 0xffffffff MMIO read
return from the device, which can be caused by a PCIe link flap or some
other kind of PCI bus error, and to avoid performing MMIO reads and
writes from that point onwards.
However, the IGC_REMOVED macro was not originally implemented:
#ifndef IGC_REMOVED
#define IGC_REMOVED(a) (0)
#endif /* IGC_REMOVED */
This led to the IGC_REMOVED logic to be removed entirely in a
subsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVED
function"), with the rationale that such checks matter only for
virtualization and that igc does not support virtualization -- but a
PCIe device can become detached even without virtualization being in
use, and without proper checks, a PCIe bus error affecting an igc
adapter will lead to various NULL pointer dereferences, as the first
access after the error will set hw->hw_addr to NULL, and subsequent
accesses will blindly dereference this now-NULL pointer.
This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and
implements IGC_REMOVED the way it is done for igb, by checking for the
unlikely() case of hw_addr being NULL. This change prevents the oopses
seen when a PCIe link flap occurs on an igc adapter.
CVE-2022-49605
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()
Yang Jihing reported a race between perf_event_set_output() and
perf_mmap_close():
CPU1 CPU2
perf_mmap_close(e2)
if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0
detach_rest = true
ioctl(e1, IOC_SET_OUTPUT, e2)
perf_event_set_output(e1, e2)
...
list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry)
ring_buffer_attach(e, NULL);
// e1 isn't yet added and
// therefore not detached
ring_buffer_attach(e1, e2->rb)
list_add_rcu(&e1->rb_entry,
&e2->rb->event_list)
After this; e1 is attached to an unmapped rb and a subsequent
perf_mmap() will loop forever more:
again:
mutex_lock(&e->mmap_mutex);
if (event->rb) {
...
if (!atomic_inc_not_zero(&e->rb->mmap_count)) {
...
mutex_unlock(&e->mmap_mutex);
goto again;
}
}
The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach
in perf_event_set_output() holds e1->mmap_mutex. As such there is no
serialization to avoid this race.
Change perf_event_set_output() to take both e1->mmap_mutex and
e2->mmap_mutex to alleviate that problem. Additionally, have the loop
in perf_mmap() detach the rb directly, this avoids having to wait for
the concurrent perf_mmap_close() to get around to doing it to make
progress.
CVE-2022-49607
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Prevent RSB underflow before vmenter
On VMX, there are some balanced returns between the time the guest's
SPEC_CTRL value is written, and the vmenter.
Balanced returns (matched by a preceding call) are usually ok, but it's
at least theoretically possible an NMI with a deep call stack could
empty the RSB before one of the returns.
For maximum paranoia, don't allow *any* returns (balanced or otherwise)
between the SPEC_CTRL write and the vmenter.
[ bp: Fix 32-bit build. ]
CVE-2022-49610
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: sfp: fix memory leak in sfp_probe()
sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When
devm_add_action() fails, sfp is not freed, which leads to a memory leak.
We should use devm_add_action_or_reset() instead of devm_add_action().
CVE-2022-49619
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
net: tipc: fix possible refcount leak in tipc_sk_create()
Free sk in case tipc_sk_insert() fails.
CVE-2022-49620
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: avoid skb access on nf_stolen
When verdict is NF_STOLEN, the skb might have been freed.
When tracing is enabled, this can result in a use-after-free:
1. access to skb->nf_trace
2. access to skb->mark
3. computation of trace id
4. dump of packet payload
To avoid 1, keep a cached copy of skb->nf_trace in the
trace state struct.
Refresh this copy whenever verdict is != STOLEN.
Avoid 2 by skipping skb->mark access if verdict is STOLEN.
3 is avoided by precomputing the trace id.
Only dump the packet when verdict is not "STOLEN".
CVE-2022-49622
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive/spapr: correct bitmap allocation size
kasan detects access beyond the end of the xibm->bitmap allocation:
BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140
Read of size 8 at addr c00000001d1d0118 by task swapper/0/1
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28
Call Trace:
[c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable)
[c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710
[c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354
[c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0
[c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140
[c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260
[c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450
[c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118
[c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac
[c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640
[c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0
[c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64
Allocated by task 0:
kasan_save_stack+0x34/0x70
__kasan_kmalloc+0xb4/0xf0
__kmalloc+0x268/0x540
xive_spapr_init+0x4d0/0x77c
pseries_init_irq+0x40/0x27c
init_IRQ+0x44/0x84
start_kernel+0x2a4/0x538
start_here_common+0x1c/0x20
The buggy address belongs to the object at c00000001d1d0118
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
8-byte region [c00000001d1d0118, c00000001d1d0120)
The buggy address belongs to the physical page:
page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d
flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff)
raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480
raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
>c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc
^
c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc
c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc
This happens because the allocation uses the wrong unit (bits) when it
should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small
numbers of bits, the allocated object can be smaller than sizeof(long),
which results in invalid accesses.
Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with
bitmap_free() for consistency.
CVE-2022-49623
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sfc: fix kernel panic when creating VF
When creating VFs a kernel panic can happen when calling to
efx_ef10_try_update_nic_stats_vf.
When releasing a DMA coherent buffer, sometimes, I don't know in what
specific circumstances, it has to unmap memory with vunmap. It is
disallowed to do that in IRQ context or with BH disabled. Otherwise, we
hit this line in vunmap, causing the crash:
BUG_ON(in_interrupt());
This patch reenables BH to release the buffer.
Log messages when the bug is hit:
kernel BUG at mm/vmalloc.c:2727!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1
Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020
RIP: 0010:vunmap+0x2e/0x30
...skip...
Call Trace:
__iommu_dma_free+0x96/0x100
efx_nic_free_buffer+0x2b/0x40 [sfc]
efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc]
efx_ef10_update_stats_vf+0x18/0x40 [sfc]
efx_start_all+0x15e/0x1d0 [sfc]
efx_net_open+0x5a/0xe0 [sfc]
__dev_open+0xe7/0x1a0
__dev_change_flags+0x1d7/0x240
dev_change_flags+0x21/0x60
...skip...
CVE-2022-49625
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/selftests: fix subtraction overflow bug
On some machines hole_end can be small enough to cause subtraction
overflow. On the other side (addr + 2 * min_alignment) can overflow
in case of mock tests. This patch should handle both cases.
(cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)
CVE-2022-49635
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sysctl: Fix data races in proc_douintvec_minmax().
A sysctl variable is accessed concurrently, and there is always a chance
of data-race. So, all readers and writers need some basic protection to
avoid load/store-tearing.
This patch changes proc_douintvec_minmax() to use READ_ONCE() and
WRITE_ONCE() internally to fix data-races on the sysctl side. For now,
proc_douintvec_minmax() itself is tolerant to a data-race, but we still
need to add annotations on the other subsystem's side.
CVE-2022-49640
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sysctl: Fix data races in proc_douintvec().
A sysctl variable is accessed concurrently, and there is always a chance
of data-race. So, all readers and writers need some basic protection to
avoid load/store-tearing.
This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()
internally to fix data-races on the sysctl side. For now, proc_douintvec()
itself is tolerant to a data-race, but we still need to add annotations on
the other subsystem's side.
CVE-2022-49641
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cgroup: Use separate src/dst nodes when preloading css_sets for migration
Each cset (css_set) is pinned by its tasks. When we're moving tasks around
across csets for a migration, we need to hold the source and destination
csets to ensure that they don't go away while we're moving tasks about. This
is done by linking cset->mg_preload_node on either the
mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the
same cset->mg_preload_node for both the src and dst lists was deemed okay as
a cset can't be both the source and destination at the same time.
Unfortunately, this overloading becomes problematic when multiple tasks are
involved in a migration and some of them are identity noop migrations while
others are actually moving across cgroups. For example, this can happen with
the following sequence on cgroup1:
#1> mkdir -p /sys/fs/cgroup/misc/a/b
#2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs
#3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &
#4> PID=$!
#5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks
#6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs
the process including the group leader back into a. In this final migration,
non-leader threads would be doing identity migration while the group leader
is doing an actual one.
After #3, let's say the whole process was in cset A, and that after #4, the
leader moves to cset B. Then, during #6, the following happens:
1. cgroup_migrate_add_src() is called on B for the leader.
2. cgroup_migrate_add_src() is called on A for the other threads.
3. cgroup_migrate_prepare_dst() is called. It scans the src list.
4. It notices that B wants to migrate to A, so it tries to A to the dst
list but realizes that its ->mg_preload_node is already busy.
5. and then it notices A wants to migrate to A as it's an identity
migration, it culls it by list_del_init()'ing its ->mg_preload_node and
putting references accordingly.
6. The rest of migration takes place with B on the src list but nothing on
the dst list.
This means that A isn't held while migration is in progress. If all tasks
leave A before the migration finishes and the incoming task pins it, the
cset will be destroyed leading to use-after-free.
This is caused by overloading cset->mg_preload_node for both src and dst
preload lists. We wanted to exclude the cset from the src list but ended up
inadvertently excluding it from the dst list too.
This patch fixes the issue by separating out cset->mg_preload_node into
->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst
preloadings don't interfere with each other.
CVE-2022-49647
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue
xenvif_rx_next_skb() is expecting the rx queue not being empty, but
in case the loop in xenvif_rx_action() is doing multiple iterations,
the availability of another skb in the rx queue is not being checked.
This can lead to crashes:
[40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
[40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback]
[40072.537534] PGD 0 P4D 0
[40072.537644] Oops: 0000 [#1] SMP NOPTI
[40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5
[40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021
[40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000
[40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback]
[40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246
[40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7
[40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8
[40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008
[40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708
[40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0
[40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000
[40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660
[40072.539211] Call Trace:
[40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback]
[40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]
Fix that by stopping the loop in case the rx queue becomes empty.
CVE-2022-49649
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not needed anymore.
Add missing of_node_put() in to fix this.
CVE-2022-49652
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usbnet: fix memory leak in error case
usbnet_write_cmd_async() mixed up which buffers
need to be freed in which error case.
v2: add Fixes tag
v3: fix uninitialized buf pointer
CVE-2022-49657
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals
Kuee reported a corner case where the tnum becomes constant after the call
to __reg_bound_offset(), but the register's bounds are not, that is, its
min bounds are still not equal to the register's max bounds.
This in turn allows to leak pointers through turning a pointer register as
is into an unknown scalar via adjust_ptr_min_max_vals().
Before:
func#0 @0
0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0))
1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))
2: (87) r3 = -r3 ; R3_w=scalar()
3: (87) r3 = -r3 ; R3_w=scalar()
4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881)
5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
6: (95) exit
from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
8: (95) exit
from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*]
10: (95) exit
What can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff;
0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, that
is, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off has
not been done at that point via __update_reg_bounds(), which would have improved
the umax to be equal to umin.
Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync()
helper and use it consistently everywhere. After the fix, bounds have been
corrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the register
is regarded as a 'proper' constant scalar of 0.
After:
func#0 @0
0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0))
1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))
2: (87) r3 = -r3 ; R3_w=scalar()
3: (87) r3 = -r3 ; R3_w=scalar()
4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881)
5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
6: (95) exit
from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
8: (95) exit
from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0
---truncated---
CVE-2022-49658
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix use-after-free after 802.3ad slave unbind
commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"),
resolve case, when there is several aggregation groups in the same bond.
bond_3ad_unbind_slave will invalidate (clear) aggregator when
__agg_active_ports return zero. So, ad_clear_agg can be executed even, when
num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,
previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave
will not update slave ports list, because lag_ports==NULL. So, here we
got slave ports, pointing to freed aggregator memory.
Fix with checking actual number of ports in group (as was before
commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ),
before ad_clear_agg().
The KASAN logs are as follows:
[ 767.617392] ==================================================================
[ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470
[ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767
[ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15
[ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)
[ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler
[ 767.666468] Call trace:
[ 767.668930] dump_backtrace+0x0/0x2d0
[ 767.672625] show_stack+0x24/0x30
[ 767.675965] dump_stack_lvl+0x68/0x84
[ 767.679659] print_address_description.constprop.0+0x74/0x2b8
[ 767.685451] kasan_report+0x1f0/0x260
[ 767.689148] __asan_load2+0x94/0xd0
[ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470
CVE-2022-49667
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events
of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
This function only calls of_node_put() in normal path,
missing it in error paths.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-49668
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: tun: unlink NAPI from device on destruction
Syzbot found a race between tun file and device destruction.
NAPIs live in struct tun_file which can get destroyed before
the netdev so we have to del them explicitly. The current
code is missing deleting the NAPI if the queue was detached
first.
CVE-2022-49672
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm raid: fix KASAN warning in raid5_add_disks
There's a KASAN warning in raid5_add_disk when running the LVM testsuite.
The warning happens in the test
lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning
by verifying that rdev->saved_raid_disk is within limits.
CVE-2022-49673
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm raid: fix accesses beyond end of raid member array
On dm-raid table load (using raid_ctr), dm-raid allocates an array
rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks
is defined by the number of raid metadata and image tupples passed
into the target's constructor.
In the case of RAID layout changes being requested, that number can be
different from the current number of members for existing raid sets as
defined in their superblocks. Example RAID layout changes include:
- raid1 legs being added/removed
- raid4/5/6/10 number of stripes changed (stripe reshaping)
- takeover to higher raid level (e.g. raid5 -> raid6)
When accessing array members, rs->raid_disks must be used in control
loops instead of the potentially larger value in rs->md.raid_disks.
Otherwise it will cause memory access beyond the end of the rs->devs
array.
Fix this by changing code that is prone to out-of-bounds access.
Also fix validate_raid_redundancy() to validate all devices that are
added. Also, use braces to help clean up raid_iterate_devices().
The out-of-bounds memory accesses was discovered using KASAN.
This commit was verified to pass all LVM2 RAID tests (with KASAN
enabled).
CVE-2022-49674
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix xdp_rxq_info bug after suspend/resume
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
<resume>
# ip link set eth0 down
Missing register, driver bug
WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60
Call trace:
xdp_rxq_info_unreg+0x58/0x60
virtnet_close+0x58/0xac
__dev_close_many+0xac/0x140
__dev_change_flags+0xd8/0x210
dev_change_flags+0x24/0x64
do_setlink+0x230/0xdd0
...
This happens because virtnet_freeze() frees the receive_queue
completely (including struct xdp_rxq_info) but does not call
xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the
receive_queue again but does not call xdp_rxq_info_reg().
Actually, parts of virtnet_freeze_down() and virtnet_restore_up()
are almost identical to virtnet_close() and virtnet_open(): only
the calls to xdp_rxq_info_(un)reg() are missing. This means that
we can fix this easily and avoid such problems in the future by
just calling virtnet_close()/open() from the freeze/restore handlers.
Aside from adding the missing xdp_rxq_info calls the only difference
is that the refill work is only cancelled if netif_running(). However,
this should not make any functional difference since the refill work
should only be active if the network interface is actually up.
CVE-2022-49687
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf
of_graph_get_remote_node() returns remote device node pointer with
refcount incremented, we should use of_node_put() on it
when not need anymore.
Add missing of_node_put() to avoid refcount leak.
Patchwork: https://patchwork.freedesktop.org/patch/488473/
CVE-2022-49693
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: add reserved GDT blocks check
We capture a NULL pointer issue when resizing a corrupt ext4 image which
is freshly clear resize_inode feature (not run e2fsck). It could be
simply reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
not reduced to zero, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.
mkfs.ext4 /dev/sda 3G
tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
mount /dev/sda /mnt
resize2fs /dev/sda 8G
========
BUG: kernel NULL pointer dereference, address: 0000000000000028
CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
...
RIP: 0010:ext4_flex_group_add+0xe08/0x2570
...
Call Trace:
<TASK>
ext4_resize_fs+0xbec/0x1660
__ext4_ioctl+0x1749/0x24e0
ext4_ioctl+0x12/0x20
__x64_sys_ioctl+0xa6/0x110
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f2dd739617b
========
The fix is simple, add a check in ext4_resize_begin() to make sure that
the es->s_reserved_gdt_blocks is zero when the resize_inode feature is
disabled.
CVE-2022-49707
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on ext4_mb_use_inode_pa
Hulk Robot reported a BUG_ON:
==================================================================
kernel BUG at fs/ext4/mballoc.c:3211!
[...]
RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f
[...]
Call Trace:
ext4_mb_new_blocks+0x9df/0x5d30
ext4_ext_map_blocks+0x1803/0x4d80
ext4_map_blocks+0x3a4/0x1a10
ext4_writepages+0x126d/0x2c30
do_writepages+0x7f/0x1b0
__filemap_fdatawrite_range+0x285/0x3b0
file_write_and_wait_range+0xb1/0x140
ext4_sync_file+0x1aa/0xca0
vfs_fsync_range+0xfb/0x260
do_fsync+0x48/0xa0
[...]
==================================================================
Above issue may happen as follows:
-------------------------------------
do_fsync
vfs_fsync_range
ext4_sync_file
file_write_and_wait_range
__filemap_fdatawrite_range
do_writepages
ext4_writepages
mpage_map_and_submit_extent
mpage_map_one_extent
ext4_map_blocks
ext4_mb_new_blocks
ext4_mb_normalize_request
>>> start + size <= ac->ac_o_ex.fe_logical
ext4_mb_regular_allocator
ext4_mb_simple_scan_group
ext4_mb_use_best_found
ext4_mb_new_preallocation
ext4_mb_new_inode_pa
ext4_mb_use_inode_pa
>>> set ac->ac_b_ex.fe_len <= 0
ext4_mb_mark_diskspace_used
>>> BUG_ON(ac->ac_b_ex.fe_len <= 0);
we can easily reproduce this problem with the following commands:
`fallocate -l100M disk`
`mkfs.ext4 -b 1024 -g 256 disk`
`mount disk /mnt`
`fsstress -d /mnt -l 0 -n 1000 -p 1`
The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP.
Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur
when the size is truncated. So start should be the start position of
the group where ac_o_ex.fe_logical is located after alignment.
In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP
is very large, the value calculated by start_off is more accurate.
CVE-2022-49708
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm mirror log: round up region bitmap size to BITS_PER_LONG
The code in dm-log rounds up bitset_size to 32 bits. It then uses
find_next_zero_bit_le on the allocated region. find_next_zero_bit_le
accesses the bitmap using unsigned long pointers. So, on 64-bit
architectures, it may access 4 bytes beyond the allocated size.
Fix this bug by rounding up bitset_size to BITS_PER_LONG.
This bug was found by running the lvm2 testsuite with kasan.
CVE-2022-49710
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()
In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to
fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in
fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io
triggers KASAN use-after-free. To avoid the use-after-free, keep the
reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to
fsl_destroy_mc_io().
This patch needs rework to apply to kernels older than v5.15.
CVE-2022-49711
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: Fix memory leak in dwc2_hcd_init
usb_create_hcd will alloc memory for hcd, and we should
call usb_put_hcd to free it when platform_get_resource()
fails to prevent memory leak.
goto error2 label instead error1 to fix this.
CVE-2022-49713
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions
of_find_node_by_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-49715
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix call trace in setup_tx_descriptors
After PF reset and ethtool -t there was call trace in dmesg
sometimes leading to panic. When there was some time, around 5
seconds, between reset and test there were no errors.
Problem was that pf reset calls i40e_vsi_close in prep_for_reset
and ethtool -t calls i40e_vsi_close in diag_test. If there was not
enough time between those commands the second i40e_vsi_close starts
before previous i40e_vsi_close was done which leads to crash.
Add check to diag_test if pf is in reset and don't start offline
tests if it is true.
Add netif_info("testing failed") into unhappy path of i40e_diag_test()
CVE-2022-49725
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg
When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be
overflow. To fix, we can follow what udpv6 does and subtract the
transhdrlen from the max.
CVE-2022-49727
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix signed integer overflow in __ip6_append_data
Resurrect ubsan overflow checks and ubsan report this warning,
fix it by change the variable [length] type to size_t.
UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19
2147479552 + 8567 cannot be represented in type 'int'
CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x214/0x230
show_stack+0x30/0x78
dump_stack_lvl+0xf8/0x118
dump_stack+0x18/0x30
ubsan_epilogue+0x18/0x60
handle_overflow+0xd0/0xf0
__ubsan_handle_add_overflow+0x34/0x44
__ip6_append_data.isra.48+0x1598/0x1688
ip6_append_data+0x128/0x260
udpv6_sendmsg+0x680/0xdd0
inet6_sendmsg+0x54/0x90
sock_sendmsg+0x70/0x88
____sys_sendmsg+0xe8/0x368
___sys_sendmsg+0x98/0xe0
__sys_sendmmsg+0xf4/0x3b8
__arm64_sys_sendmmsg+0x34/0x48
invoke_syscall+0x64/0x160
el0_svc_common.constprop.4+0x124/0x300
do_el0_svc+0x44/0xc8
el0_svc+0x3c/0x1e8
el0t_64_sync_handler+0x88/0xb0
el0t_64_sync+0x16c/0x170
Changes since v1:
-Change the variable [length] type to unsigned, as Eric Dumazet suggested.
Changes since v2:
-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.
Changes since v3:
-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as
Jakub Kicinski suggested.
CVE-2022-49728
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred
Similar to the handling of play_deferred in commit 19cfe912c37b
("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought
a patch might be needed here as well.
Currently usb_submit_urb is called directly to submit deferred tx
urbs after unanchor them.
So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
and cause memory leak.
Put those urbs in tx_anchor to avoid the leak, and also fix the error
handling.
CVE-2022-49729
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2022-49730
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()
In an unlikely (and probably wrong?) case that the 'ppi' parameter of
ata_host_alloc_pinfo() points to an array starting with a NULL pointer,
there's going to be a kernel oops as the 'pi' local variable won't get
reassigned from the initial value of NULL. Initialize 'pi' instead to
'&ata_dummy_port_info' to fix the possible kernel oops for good...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
CVE-2022-49731
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads
This patch fixes slab-out-of-bounds reads in brcmfmac that occur in
brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count
value of channel specifications provided by the device is greater than
the length of 'list->element[]', decided by the size of the 'list'
allocated with kzalloc(). The patch adds checks that make the functions
free the buffer and return -EINVAL if that is the case. Note that the
negative return is handled by the caller, brcmf_setup_wiphybands() or
brcmf_cfg80211_attach().
Found by a modified version of syzkaller.
Crash Report from brcmf_construct_chaninfo():
==================================================================
BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430
Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896
CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
dump_stack_lvl+0x57/0x7d
print_address_description.constprop.0.cold+0x93/0x334
kasan_report.cold+0x83/0xdf
brcmf_setup_wiphybands+0x1238/0x1430
brcmf_cfg80211_attach+0x2118/0x3fd0
brcmf_attach+0x389/0xd40
brcmf_usb_probe+0x12de/0x1690
usb_probe_interface+0x25f/0x710
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_set_configuration+0x984/0x1770
usb_generic_driver_probe+0x69/0x90
usb_probe_device+0x9c/0x220
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_new_device.cold+0x463/0xf66
hub_event+0x10d5/0x3330
process_one_work+0x873/0x13e0
worker_thread+0x8b/0xd10
kthread+0x379/0x450
ret_from_fork+0x1f/0x30
Allocated by task 1896:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x7c/0x90
kmem_cache_alloc_trace+0x19e/0x330
brcmf_setup_wiphybands+0x290/0x1430
brcmf_cfg80211_attach+0x2118/0x3fd0
brcmf_attach+0x389/0xd40
brcmf_usb_probe+0x12de/0x1690
usb_probe_interface+0x25f/0x710
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_set_configuration+0x984/0x1770
usb_generic_driver_probe+0x69/0x90
usb_probe_device+0x9c/0x220
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
bus_for_each_drv+0x123/0x1a0
__device_attach+0x207/0x330
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
usb_new_device.cold+0x463/0xf66
hub_event+0x10d5/0x3330
process_one_work+0x873/0x13e0
worker_thread+0x8b/0xd10
kthread+0x379/0x450
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff888115f24000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1536 bytes inside of
2048-byte region [ffff888115f24000, ffff888115f24800)
Memory state around the buggy address:
ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Crash Report from brcmf_enable_bw40_2g():
==========
---truncated---
CVE-2022-49740
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: designware: use casting of u64 in clock multiplication to avoid overflow
In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow
by depending on the values of the given parameters including the ic_clk.
For example in our use case where ic_clk is larger than one million,
multiplication of ic_clk * 4700 will result in 32 bit overflow.
Add cast of u64 to the calculation to avoid multiplication overflow, and
use the corresponding define for divide.
CVE-2022-49749
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
w1: fix WARNING after calling w1_process()
I got the following WARNING message while removing driver(ds2482):
------------[ cut here ]------------
do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire]
WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0
CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307
RIP: 0010:__might_sleep+0x98/0xa0
Call Trace:
exit_signals+0x6c/0x550
do_exit+0x2b4/0x17e0
kthread_exit+0x52/0x60
kthread+0x16d/0x1e0
ret_from_fork+0x1f/0x30
The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(),
set it to TASK_RUNNING when it breaks out of the loop to avoid the
warning.
CVE-2022-49751
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: Fix double increment of client_count in dma_chan_get()
The first time dma_chan_get() is called for a channel the channel
client_count is incorrectly incremented twice for public channels,
first in balance_ref_count(), and again prior to returning. This
results in an incorrect client count which will lead to the
channel resources not being freed when they should be. A simple
test of repeated module load and unload of async_tx on a Dell
Power Edge R7425 also shows this resulting in a kref underflow
warning.
[ 124.329662] async_tx: api initialized (async)
[ 129.000627] async_tx: api initialized (async)
[ 130.047839] ------------[ cut here ]------------
[ 130.052472] refcount_t: underflow; use-after-free.
[ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28
refcount_warn_saturate+0xba/0x110
[ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr
intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm
mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si
syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops
k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat
fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul
libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas
i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: async_tx]
[ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not
tainted 5.14.0-185.el9.x86_64 #1
[ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS
1.18.0 01/17/2022
[ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110
[ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d
26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a
bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff
48 c7
[ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286
[ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000
[ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0
[ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff
[ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970
[ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)
knlGS:0000000000000000
[ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0
[ 130.219729] Call Trace:
[ 130.222192] <TASK>
[ 130.224305] dma_chan_put+0x10d/0x110
[ 130.227988] dmaengine_put+0x7a/0xa0
[ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280
[ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0
[ 130.242652] do_syscall_64+0x5c/0x90
[ 130.246240] ? exc_page_fault+0x62/0x150
[ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 130.255243] RIP: 0033:0x7f6463a3f5ab
[ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48
83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89
01 48
[ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:
00000000000000b0
[ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab
[ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8
[ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000
[ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8
[ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8
[ 130.320875] </TASK>
[ 130.323081] ---[ end trace eff7156d56b5cf25 ]---
cat /sys/class/dma/dma0chan*/in_use would get the wrong result.
2
2
2
Test-by: Jie Hai <haijie1@huawei.com>
CVE-2022-49753
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: always report error in run_one_delayed_ref()
Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but
if end users hit such problem, there will be no chance that
btrfs_debug() is enabled. This can lead to very little useful info for
debugging.
This patch will:
- Add extra info for error reporting
Including:
* logical bytenr
* num_bytes
* type
* action
* ref_mod
- Replace the btrfs_debug() with btrfs_err()
- Move the error reporting into run_one_delayed_ref()
This is to avoid use-after-free, the @node can be freed in the caller.
This error should only be triggered at most once.
As if run_one_delayed_ref() failed, we trigger the error message, then
causing the call chain to error out:
btrfs_run_delayed_refs()
`- btrfs_run_delayed_refs()
`- btrfs_run_delayed_refs_for_head()
`- run_one_delayed_ref()
And we will abort the current transaction in btrfs_run_delayed_refs().
If we have to run delayed refs for the abort transaction,
run_one_delayed_ref() will just cleanup the refs and do nothing, thus no
new error messages would be output.
CVE-2022-49761
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Prevent bpf program recursion for raw tracepoint probes
We got report from sysbot [1] about warnings that were caused by
bpf program attached to contention_begin raw tracepoint triggering
the same tracepoint by using bpf_trace_printk helper that takes
trace_printk_lock lock.
Call Trace:
<TASK>
? trace_event_raw_event_bpf_trace_printk+0x5f/0x90
bpf_trace_printk+0x2b/0xe0
bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
bpf_trace_run2+0x26/0x90
native_queued_spin_lock_slowpath+0x1c6/0x2b0
_raw_spin_lock_irqsave+0x44/0x50
bpf_trace_printk+0x3f/0xe0
bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
bpf_trace_run2+0x26/0x90
native_queued_spin_lock_slowpath+0x1c6/0x2b0
_raw_spin_lock_irqsave+0x44/0x50
bpf_trace_printk+0x3f/0xe0
bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
bpf_trace_run2+0x26/0x90
native_queued_spin_lock_slowpath+0x1c6/0x2b0
_raw_spin_lock_irqsave+0x44/0x50
bpf_trace_printk+0x3f/0xe0
bpf_prog_a9aec6167c091eef_prog+0x1f/0x24
bpf_trace_run2+0x26/0x90
native_queued_spin_lock_slowpath+0x1c6/0x2b0
_raw_spin_lock_irqsave+0x44/0x50
__unfreeze_partials+0x5b/0x160
...
The can be reproduced by attaching bpf program as raw tracepoint on
contention_begin tracepoint. The bpf prog calls bpf_trace_printk
helper. Then by running perf bench the spin lock code is forced to
take slow path and call contention_begin tracepoint.
Fixing this by skipping execution of the bpf program if it's
already running, Using bpf prog 'active' field, which is being
currently used by trampoline programs for the same reason.
Moving bpf_prog_inc_misses_counter to syscall.c because
trampoline.c is compiled in just for CONFIG_BPF_JIT option.
[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t
CVE-2022-49764
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
9p: trans_fd/p9_conn_cancel: drop client lock earlier
syzbot reported a double-lock here and we no longer need this
lock after requests have been moved off to local list:
just drop the lock earlier.
CVE-2022-49768
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Check sb_bsize_shift after reading superblock
Fuzzers like to scribble over sb_bsize_shift but in reality it's very
unlikely that this field would be corrupted on its own. Nevertheless it
should be checked to avoid the possibility of messy mount errors due to
bad calculations. It's always a fixed value based on the block size so
we can just check that it's the expected value.
Tested with:
mkfs.gfs2 -O -p lock_nolock /dev/vdb
for i in 0 -1 64 65 32 33; do
gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb
mount /dev/vdb /mnt/test && umount /mnt/test
done
Before this patch we get a withdraw after
[ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block
[ 76.413681] bh = 19 (type: exp=5, found=4)
[ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492
and with UBSAN configured we also get complaints like
[ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19
[ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'
After the patch, these complaints don't appear, mount fails immediately
and we get an explanation in dmesg.
CVE-2022-49769
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm ioctl: fix misbehavior if list_versions races with module loading
__list_versions will first estimate the required space using the
"dm_target_iterate(list_version_get_needed, &needed)" call and then will
fill the space using the "dm_target_iterate(list_version_get_info,
&iter_info)" call. Each of these calls locks the targets using the
"down_read(&_lock)" and "up_read(&_lock)" calls, however between the first
and second "dm_target_iterate" there is no lock held and the target
modules can be loaded at this point, so the second "dm_target_iterate"
call may need more space than what was the first "dm_target_iterate"
returned.
The code tries to handle this overflow (see the beginning of
list_version_get_info), however this handling is incorrect.
The code sets "param->data_size = param->data_start + needed" and
"iter_info.end = (char *)vers+len" - "needed" is the size returned by the
first dm_target_iterate call; "len" is the size of the buffer allocated by
userspace.
"len" may be greater than "needed"; in this case, the code will write up
to "len" bytes into the buffer, however param->data_size is set to
"needed", so it may write data past the param->data_size value. The ioctl
interface copies only up to param->data_size into userspace, thus part of
the result will be truncated.
Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this
guarantees that the second "dm_target_iterate" call will write only up to
the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it
overflows the "needed" space - in this case, userspace will allocate a
larger buffer and retry.
Note that there is also a bug in list_version_get_needed - we need to add
"strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".
CVE-2022-49771
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open()
snd_usbmidi_output_open() has a check of the NULL port with
snd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened,
but in reality, the NULL port may be seen when the device gives an
invalid endpoint setup at the descriptor, hence the driver skips the
allocation. That is, the check itself is valid and snd_BUG_ON()
should be dropped from there. Otherwise it's confusing as if it were
a real bug, as recently syzbot stumbled on it.
CVE-2022-49772
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: cdg: allow tcp_cdg_release() to be called multiple times
Apparently, mptcp is able to call tcp_disconnect() on an already
disconnected flow. This is generally fine, unless current congestion
control is CDG, because it might trigger a double-free [1]
Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect()
more resilient.
[1]
BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]
BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567
CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: events mptcp_worker
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462
____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356
kasan_slab_free include/linux/kasan.h:200 [inline]
slab_free_hook mm/slub.c:1759 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785
slab_free mm/slub.c:3539 [inline]
kfree+0xe2/0x580 mm/slub.c:4567
tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145
__mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327
mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline]
mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627
process_one_work+0x991/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Allocated by task 3671:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
____kasan_kmalloc mm/kasan/common.c:516 [inline]
____kasan_kmalloc mm/kasan/common.c:475 [inline]
__kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525
kmalloc_array include/linux/slab.h:640 [inline]
kcalloc include/linux/slab.h:671 [inline]
tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380
tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193
tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline]
tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391
do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513
tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801
mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844
__sys_setsockopt+0x2d6/0x690 net/socket.c:2252
__do_sys_setsockopt net/socket.c:2263 [inline]
__se_sys_setsockopt net/socket.c:2260 [inline]
__x64_sys_setsockopt+0xba/0x150 net/socket.c:2260
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 16:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:367 [inline]
____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329
kasan_slab_free include/linux/kasan.h:200 [inline]
slab_free_hook mm/slub.c:1759 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785
slab_free mm/slub.c:3539 [inline]
kfree+0xe2/0x580 mm/slub.c:4567
tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226
tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254
tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969
inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157
tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649
tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624
tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525
tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759
ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439
ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484
NF_HOOK include/linux/netfilter.h:302 [inline]
NF_HOOK include/linux/netfilter.h:296 [inline]
ip6_input+0x9c/0xd
---truncated---
CVE-2022-49775
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
macvlan: enforce a consistent minimal mtu
macvlan should enforce a minimal mtu of 68, even at link creation.
This patch avoids the current behavior (which could lead to crashes
in ipv6 stack if the link is brought up)
$ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail !
$ ip link sh dev macvlan1
5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop
state DOWN mode DEFAULT group default qlen 1000
link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff
$ ip link set macvlan1 mtu 67
Error: mtu less than device minimum.
$ ip link set macvlan1 mtu 68
$ ip link set macvlan1 mtu 8
Error: mtu less than device minimum.
CVE-2022-49776
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()
If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated
by dev_set_name() need be freed. As comment of device_register() says, it
should use put_device() to give up the reference in the error path. So fix
this by calling put_device(), then the name can be freed in kobject_cleanup().
The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need
goto error label in this case.
CVE-2022-49780
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()
pci_get_device() will increase the reference count for the returned
pci_dev. We need to use pci_dev_put() to decrease the reference count
before amd_probe() returns. There is no problem for the 'smbus_dev ==
NULL' branch because pci_dev_put() can also handle the NULL input
parameter case.
CVE-2022-49787
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()
`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,
which may carry uninitialized data to the userspace, as observed by
KMSAN:
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121
instrument_copy_to_user ./include/linux/instrumented.h:121
_copy_to_user+0x5f/0xb0 lib/usercopy.c:33
copy_to_user ./include/linux/uaccess.h:169
vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431
vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925
vfs_ioctl fs/ioctl.c:51
...
Uninit was stored to memory at:
kmemdup+0x74/0xb0 mm/util.c:131
dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271
vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339
qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479
qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940
vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488
vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927
...
Local variable ev created at:
qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456
qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
Bytes 28-31 of 48 are uninitialized
Memory access of size 48 starts at ffff888035155e00
Data copied to user address 0000000020000100
Use memset() to prevent the infoleaks.
Also speculatively fix qp_notify_peer_local(), which may suffer from the
same problem.
CVE-2022-49788
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: zfcp: Fix double free of FSF request when qdio send fails
We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache
the FSF request ID when sending a new FSF request. This is used in case the
sending fails and we need to remove the request from our internal hash
table again (so we don't keep an invalid reference and use it when we free
the request again).
In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32
bit wide), but the rest of the zfcp code (and the firmware specification)
handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x
ELF ABI]). For one this has the obvious problem that when the ID grows
past 32 bit (this can happen reasonably fast) it is truncated to 32 bit
when storing it in the cache variable and so doesn't match the original ID
anymore. The second less obvious problem is that even when the original ID
has not yet grown past 32 bit, as soon as the 32nd bit is set in the
original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we
cast it back to 'unsigned long'. As the cached variable is of a signed
type, the compiler will choose a sign-extending instruction to load the 32
bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once
we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the
request again all the leading zeros will be flipped to ones to extend the
sign and won't match the original ID anymore (this has been observed in
practice).
If we can't successfully remove the request from the hash table again after
'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify
the adapter about new work because the adapter is already gone during
e.g. a ChpID toggle) we will end up with a double free. We unconditionally
free the request in the calling function when 'zfcp_fsf_req_send()' fails,
but because the request is still in the hash table we end up with a stale
memory reference, and once the zfcp adapter is either reset during recovery
or shutdown we end up freeing the same memory twice.
The resulting stack traces vary depending on the kernel and have no direct
correlation to the place where the bug occurs. Here are three examples that
have been seen in practice:
list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:62!
monitor event: 0040 ilc:2 [#1] PREEMPT SMP
Modules linked in: ...
CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded
Hardware name: ...
Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3
Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6
0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8
00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800
00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70
Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336
00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8
#00000003cbeea1f4: af000000 mc 0,0
>00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78
00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48
00000003cbeea204: b9040043 lgr %r4,%r3
00000003cbeea208: b9040051 lgr %r5,%r1
00000003cbeea20c: b9040032 lgr %r3,%r2
Call Trace:
[<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140
([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140)
[<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]
[<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]
---truncated---
CVE-2022-49789
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: ena: Fix error handling in ena_init()
The ena_init() won't destroy workqueue created by
create_singlethread_workqueue() when pci_register_driver() failed.
Call destroy_workqueue() when pci_register_driver() failed to prevent the
resource leak.
CVE-2022-49813
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kcm: close race conditions on sk_receive_queue
sk->sk_receive_queue is protected by skb queue lock, but for KCM
sockets its RX path takes mux->rx_lock to protect more than just
skb queue. However, kcm_recvmsg() still only grabs the skb queue
lock, so race conditions still exist.
We can teach kcm_recvmsg() to grab mux->rx_lock too but this would
introduce a potential performance regression as struct kcm_mux can
be shared by multiple KCM sockets.
So we have to enforce skb queue lock in requeue_rx_msgs() and handle
skb peek case carefully in kcm_wait_data(). Fortunately,
skb_recv_datagram() already handles it nicely and is widely used by
other sockets, we can just switch to skb_recv_datagram() after
getting rid of the unnecessary sock lock in kcm_recvmsg() and
kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,
so it is safe to get rid of this check too.
I ran the original syzbot reproducer for 30 min without seeing any
issue.
CVE-2022-49814
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible memory leak in mISDN_dsp_element_register()
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
use put_device() to give up the reference, so that the name can be
freed in kobject_cleanup() when the refcount is 0.
The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the
kfree() is removed. list_del() is called in mISDN_dsp_dev_release(),
so it need be initialized.
CVE-2022-49821
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix connections leak when tlink setup failed
If the tlink setup failed, lost to put the connections, then
the module refcnt leak since the cifsd kthread not exit.
Also leak the fscache info, and for next mount with fsc, it will
print the follow errors:
CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)
Let's check the result of tlink setup, and do some cleanup.
CVE-2022-49822
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-transport: fix error handling in ata_tport_add()
In ata_tport_add(), the return value of transport_add_device() is
not checked. As a result, it causes null-ptr-deref while removing
the module, because transport_remove_device() is called to remove
the device that was not added.
Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x48/0x39c
lr : device_del+0x44/0x39c
Call trace:
device_del+0x48/0x39c
attribute_container_class_device_del+0x28/0x40
transport_remove_classdev+0x60/0x7c
attribute_container_device_trigger+0x118/0x120
transport_remove_device+0x20/0x30
ata_tport_delete+0x34/0x60 [libata]
ata_port_detach+0x148/0x1b0 [libata]
ata_pci_remove_one+0x50/0x80 [libata]
ahci_remove_one+0x4c/0x8c [ahci]
Fix this by checking and handling return value of transport_add_device()
in ata_tport_add().
CVE-2022-49825
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-transport: fix double ata_host_put() in ata_tport_add()
In the error path in ata_tport_add(), when calling put_device(),
ata_tport_release() is called, it will put the refcount of 'ap->host'.
And then ata_host_put() is called again, the refcount is decreased
to 0, ata_host_release() is called, all ports are freed and set to
null.
When unbinding the device after failure, ata_host_stop() is called
to release the resources, it leads a null-ptr-deref(), because all
the ports all freed and null.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ata_host_stop+0x3c/0x84 [libata]
lr : release_nodes+0x64/0xd0
Call trace:
ata_host_stop+0x3c/0x84 [libata]
release_nodes+0x64/0xd0
devres_release_all+0xbc/0x1b0
device_unbind_cleanup+0x20/0x70
really_probe+0x158/0x320
__driver_probe_device+0x84/0x120
driver_probe_device+0x44/0x120
__driver_attach+0xb4/0x220
bus_for_each_dev+0x78/0xdc
driver_attach+0x2c/0x40
bus_add_driver+0x184/0x240
driver_register+0x80/0x13c
__pci_register_driver+0x4c/0x60
ahci_pci_driver_init+0x30/0x1000 [ahci]
Fix this by removing redundant ata_host_put() in the error path.
CVE-2022-49826
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/scheduler: fix fence ref counting
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.
CVE-2022-49829
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map
Here is the BUG report by KASAN about null pointer dereference:
BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50
Read of size 1 at addr 0000000000000000 by task python3/2640
Call Trace:
strcmp
__of_find_property
of_find_property
pinctrl_dt_to_map
kasprintf() would return NULL pointer when kmalloc() fail to allocate.
So directly return ENOMEM, if kasprintf() return NULL pointer.
CVE-2022-49832
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: fix potential memleak in 'add_widget_node'
As 'kobject_add' may allocated memory for 'kobject->name' when return error.
And in this function, if call 'kobject_add' failed didn't free kobject.
So call 'kobject_put' to recycling resources.
CVE-2022-49835
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()
We got a syzkaller problem because of aarch64 alignment fault
if KFENCE enabled. When the size from user bpf program is an odd
number, like 399, 407, etc, it will cause the struct skb_shared_info's
unaligned access. As seen below:
BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
__lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]
arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]
atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]
__skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
skb_clone+0xf4/0x214 net/core/skbuff.c:1481
____bpf_clone_redirect net/core/filter.c:2433 [inline]
bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420
bpf_prog_d3839dd9068ceb51+0x80/0x330
bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]
bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53
bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594
bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
__do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
__se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512
allocated by task 15074 on cpu 0 at 1342.585390s:
kmalloc include/linux/slab.h:568 [inline]
kzalloc include/linux/slab.h:675 [inline]
bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191
bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512
bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
__do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
__se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
__arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381
To fix the problem, we adjust @size so that (@size + @hearoom) is a
multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info
is aligned to a cache line.
CVE-2022-49840
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Fix use-after-free in snd_soc_exit()
KASAN reports a use-after-free:
BUG: KASAN: use-after-free in device_del+0xb5b/0xc60
Read of size 8 at addr ffff888008655050 by task rmmod/387
CPU: 2 PID: 387 Comm: rmmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
<TASK>
dump_stack_lvl+0x79/0x9a
print_report+0x17f/0x47b
kasan_report+0xbb/0xf0
device_del+0xb5b/0xc60
platform_device_del.part.0+0x24/0x200
platform_device_unregister+0x2e/0x40
snd_soc_exit+0xa/0x22 [snd_soc_core]
__do_sys_delete_module.constprop.0+0x34f/0x5b0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
...
</TASK>
It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,
but its ret is ignored, which makes soc_dummy_dev unregistered twice.
snd_soc_init()
snd_soc_util_init()
platform_device_register_simple(soc_dummy_dev)
platform_driver_register() # fail
platform_device_unregister(soc_dummy_dev)
platform_driver_register() # success
...
snd_soc_exit()
snd_soc_util_exit()
# soc_dummy_dev will be unregistered for second time
To fix it, handle error and stop snd_soc_init() when util_init() fail.
Also clean debugfs when util_init() or driver_register() fail.
CVE-2022-49842
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix a slab-out-of-bounds write bug in udf_find_entry()
Syzbot reported a slab-out-of-bounds Write bug:
loop0: detected capacity change from 0 to 2048
==================================================================
BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0
fs/udf/namei.c:253
Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610
CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/11/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
print_address_description+0x74/0x340 mm/kasan/report.c:284
print_report+0x107/0x1f0 mm/kasan/report.c:395
kasan_report+0xcd/0x100 mm/kasan/report.c:495
kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189
memcpy+0x3c/0x60 mm/kasan/shadow.c:66
udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253
udf_lookup+0xef/0x340 fs/udf/namei.c:309
lookup_open fs/namei.c:3391 [inline]
open_last_lookups fs/namei.c:3481 [inline]
path_openat+0x10e6/0x2df0 fs/namei.c:3710
do_filp_open+0x264/0x4f0 fs/namei.c:3740
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_creat fs/open.c:1402 [inline]
__se_sys_creat fs/open.c:1396 [inline]
__x64_sys_creat+0x11f/0x160 fs/open.c:1396
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7ffab0d164d9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9
RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180
RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000
R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Allocated by task 3610:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
____kasan_kmalloc mm/kasan/common.c:371 [inline]
__kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380
kmalloc include/linux/slab.h:576 [inline]
udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243
udf_lookup+0xef/0x340 fs/udf/namei.c:309
lookup_open fs/namei.c:3391 [inline]
open_last_lookups fs/namei.c:3481 [inline]
path_openat+0x10e6/0x2df0 fs/namei.c:3710
do_filp_open+0x264/0x4f0 fs/namei.c:3740
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_creat fs/open.c:1402 [inline]
__se_sys_creat fs/open.c:1396 [inline]
__x64_sys_creat+0x11f/0x160 fs/open.c:1396
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The buggy address belongs to the object at ffff8880123ff800
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 150 bytes inside of
256-byte region [ffff8880123ff800, ffff8880123ff900)
The buggy address belongs to the physical page:
page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x123fe
head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(),
pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0
create_dummy_stack mm/page_owner.c:
---truncated---
CVE-2022-49846
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: macvlan: fix memory leaks of macvlan_common_newlink
kmemleak reports memory leaks in macvlan_common_newlink, as follows:
ip link add link eth0 name .. type macvlan mode source macaddr add
<MAC-ADDR>
kmemleak reports:
unreferenced object 0xffff8880109bb140 (size 64):
comm "ip", pid 284, jiffies 4294986150 (age 430.108s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z.....
80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk
backtrace:
[<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300
[<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0
[<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170
[<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0
[<ffffffff81b6797e>] macvlan_newlink+0xe/0x20
[<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50
[<ffffffff81d98278>] rtnl_newlink+0x48/0x70
...
In the scenario where the macvlan mode is configured as 'source',
macvlan_changelink_sources() will be execured to reconfigure list of
remote source mac addresses, at the same time, if register_netdevice()
return an error, the resource generated by macvlan_changelink_sources()
is not cleaned up.
Using this patch, in the case of an error, it will execute
macvlan_flush_sources() to ensure that the resource is cleaned up.
CVE-2022-49853
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove()
A clk_prepare_enable() call in the probe is not balanced by a corresponding
clk_disable_unprepare() in the remove function.
Add the missing call.
CVE-2022-49861
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header
This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value
in tipc_nl_compat_name_table_dump") where it should have type casted
sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative
value.
syzbot reported a call trace because of it:
BUG: KMSAN: uninit-value in ...
tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934
__tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238
tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321
tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324
genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792
netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501
genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
CVE-2022-49862
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network
When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved
remained uninitialized, resulting in a 1-byte infoleak:
BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841
__netdev_start_xmit ./include/linux/netdevice.h:4841
netdev_start_xmit ./include/linux/netdevice.h:4857
xmit_one net/core/dev.c:3590
dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606
__dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256
dev_queue_xmit ./include/linux/netdevice.h:3009
__netlink_deliver_tap_skb net/netlink/af_netlink.c:307
__netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325
netlink_deliver_tap net/netlink/af_netlink.c:338
__netlink_sendskb net/netlink/af_netlink.c:1263
netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272
netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360
nlmsg_unicast ./include/net/netlink.h:1061
rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758
ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628
rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082
...
Uninit was created at:
slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742
slab_alloc_node mm/slub.c:3398
__kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437
__do_kmalloc_node mm/slab_common.c:954
__kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975
kmalloc_reserve net/core/skbuff.c:437
__alloc_skb+0x27a/0xab0 net/core/skbuff.c:509
alloc_skb ./include/linux/skbuff.h:1267
nlmsg_new ./include/net/netlink.h:964
ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608
rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082
netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540
rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109
netlink_unicast_kernel net/netlink/af_netlink.c:1319
netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345
netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921
...
This patch ensures that the reserved field is always initialized.
CVE-2022-49865
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: tun: Fix memory leaks of napi_get_frags
kmemleak reports after running test_progs:
unreferenced object 0xffff8881b1672dc0 (size 232):
comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s)
hex dump (first 32 bytes):
e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g.....
00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............
backtrace:
[<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150
[<0000000041c7fc09>] __napi_build_skb+0x15/0x50
[<00000000431c7079>] __napi_alloc_skb+0x26e/0x540
[<000000003ecfa30e>] napi_get_frags+0x59/0x140
[<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun]
[<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun]
[<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320
[<000000008f338ea2>] do_iter_write+0x135/0x630
[<000000008a3377a4>] vfs_writev+0x12e/0x440
[<00000000a6b5639a>] do_writev+0x104/0x280
[<00000000ccf065d8>] do_syscall_64+0x3b/0x90
[<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
The issue occurs in the following scenarios:
tun_get_user()
napi_gro_frags()
napi_frags_finish()
case GRO_NORMAL:
gro_normal_one()
list_add_tail(&skb->list, &napi->rx_list);
<-- While napi->rx_count < READ_ONCE(gro_normal_batch),
<-- gro_normal_list() is not called, napi->rx_list is not empty
<-- not ask to complete the gro work, will cause memory leaks in
<-- following tun_napi_del()
...
tun_napi_del()
netif_napi_del()
__netif_napi_del()
<-- &napi->rx_list is not empty, which caused memory leaks
To fix, add napi_complete() after napi_gro_frags().
CVE-2022-49871
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: gso: fix panic on frag_list with mixed head alloc types
Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when
splitting gso_size mangled skb having linear-headed frag_list"), it is
allowed to change gso_size of a GRO packet. However, that commit assumes
that "checking the first list_skb member suffices; i.e if either of the
list_skb members have non head_frag head, then the first one has too".
It turns out this assumption does not hold. We've seen BUG_ON being hit
in skb_segment when skbs on the frag_list had differing head_frag with
the vmxnet3 driver. This happens because __netdev_alloc_skb and
__napi_alloc_skb can return a skb that is page backed or kmalloced
depending on the requested size. As the result, the last small skb in
the GRO packet can be kmalloced.
There are three different locations where this can be fixed:
(1) We could check head_frag in GRO and not allow GROing skbs with
different head_frag. However, that would lead to performance
regression on normal forward paths with unmodified gso_size, where
!head_frag in the last packet is not a problem.
(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating
that NETIF_F_SG is undesirable. That would need to eat a bit in
sk_buff. Furthermore, that flag can be unset when all skbs on the
frag_list are page backed. To retain good performance,
bpf_skb_net_grow/shrink would have to walk the frag_list.
(3) Walk the frag_list in skb_segment when determining whether
NETIF_F_SG should be cleared. This of course slows things down.
This patch implements (3). To limit the performance impact in
skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set
that have gso_size changed. Normal paths thus will not hit it.
We could check only the last skb but since we need to walk the whole
list anyway, let's stay on the safe side.
CVE-2022-49872
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: fix possible memory leak in mousevsc_probe()
If hid_add_device() returns error, it should call hid_destroy_device()
to free hid_dev which is allocated in hid_allocate_device().
CVE-2022-49874
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix BUG_ON() when directory entry has invalid rec_len
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
<TASK>
? add_dirent_to_buf+0x1b2/0x200
ext4_add_entry+0x36e/0x480
ext4_add_nondir+0x2b/0xc0
ext4_create+0x163/0x200
path_openat+0x635/0xe90
do_filp_open+0xb4/0x160
? __create_object.isra.0+0x1de/0x3b0
? _raw_spin_unlock+0x12/0x30
do_sys_openat2+0x91/0x150
__x64_sys_open+0x6c/0xa0
do_syscall_64+0x3c/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The fix simply adds a call to ext4_check_dir_entry() to validate the
directory entry, returning -EFSCORRUPTED if the entry is invalid.
CVE-2022-49879
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461
mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589
ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852
do_writepages+0x3c3/0x680 mm/page-writeback.c:2469
__writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587
writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870
wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044
wb_do_writeback fs/fs-writeback.c:2187 [inline]
wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227
process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Above issue may happens as follows:
ext4_da_write_begin
ext4_create_inline_data
ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
__ext4_ioctl
ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag
ext4_da_write_begin
ext4_da_convert_inline_data_to_extent
ext4_da_write_inline_data_begin
ext4_da_map_blocks
ext4_insert_delayed_block
if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk))
if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk))
ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1
allocated = true;
ext4_es_insert_delayed_block(inode, lblk, allocated);
ext4_writepages
mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC
mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1
ext4_es_remove_extent
ext4_da_release_space(inode, reserved);
if (unlikely(to_free > ei->i_reserved_data_blocks))
-> to_free == 1 but ei->i_reserved_data_blocks == 0
-> then trigger warning as above
To solve above issue, forbid inode do migrate which has inline data.
CVE-2022-49880
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: fix memory leak in query_regdb_file()
In the function query_regdb_file() the alpha2 parameter is duplicated
using kmemdup() and subsequently freed in regdb_fw_cb(). However,
request_firmware_nowait() can fail without calling regdb_fw_cb() and
thus leak memory.
CVE-2022-49881
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()
On some machines the number of listed CPUs may be bigger than the actual
CPUs that exist. The tracing subsystem allocates a per_cpu directory with
access to the per CPU ring buffer via a cpuX file. But to save space, the
ring buffer will only allocate buffers for online CPUs, even though the
CPU array will be as big as the nr_cpu_ids.
With the addition of waking waiters on the ring buffer when closing the
file, the ring_buffer_wake_waiters() now needs to make sure that the
buffer is allocated (with the irq_work allocated with it) before trying to
wake waiters, as it will cause a NULL pointer dereference.
While debugging this, I added a NULL check for the buffer itself (which is
OK to do), and also NULL pointer checks against buffer->buffers (which is
not fine, and will WARN) as well as making sure the CPU number passed in
is within the nr_cpu_ids (which is also not fine if it isn't).
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705
CVE-2022-49889
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix use-after-free for dynamic ftrace_ops
KASAN reported a use-after-free with ftrace ops [1]. It was found from
vmcore that perf had registered two ops with the same content
successively, both dynamic. After unregistering the second ops, a
use-after-free occurred.
In ftrace_shutdown(), when the second ops is unregistered, the
FTRACE_UPDATE_CALLS command is not set because there is another enabled
ops with the same content. Also, both ops are dynamic and the ftrace
callback function is ftrace_ops_list_func, so the
FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value
of 'command' will be 0 and ftrace_shutdown() will skip the rcu
synchronization.
However, ftrace may be activated. When the ops is released, another CPU
may be accessing the ops. Add the missing synchronization to fix this
problem.
[1]
BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]
BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049
Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468
CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132
show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b4/0x248 lib/dump_stack.c:118
print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387
__kasan_report mm/kasan/report.c:547 [inline]
kasan_report+0x118/0x210 mm/kasan/report.c:564
check_memory_region_inline mm/kasan/generic.c:187 [inline]
__asan_load8+0x98/0xc0 mm/kasan/generic.c:253
__ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]
ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049
ftrace_graph_call+0x0/0x4
__might_sleep+0x8/0x100 include/linux/perf_event.h:1170
__might_fault mm/memory.c:5183 [inline]
__might_fault+0x58/0x70 mm/memory.c:5171
do_strncpy_from_user lib/strncpy_from_user.c:41 [inline]
strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139
getname_flags+0xb0/0x31c fs/namei.c:149
getname+0x2c/0x40 fs/namei.c:209
[...]
Allocated by task 14445:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:48
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:479 [inline]
__kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449
kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493
kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:675 [inline]
perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230
perf_event_alloc kernel/events/core.c:11733 [inline]
__do_sys_perf_event_open kernel/events/core.c:11831 [inline]
__se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723
__arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723
[...]
Freed by task 14445:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:48
kasan_set_track+0x24/0x34 mm/kasan/common.c:56
kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358
__kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437
__kasan_slab_free mm/kasan/common.c:445 [inline]
kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446
slab_free_hook mm/slub.c:1569 [inline]
slab_free_freelist_hook mm/slub.c:1608 [inline]
slab_free mm/slub.c:3179 [inline]
kfree+0x12c/0xc10 mm/slub.c:4176
perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434
perf_event_alloc kernel/events/core.c:11733 [inline]
__do_sys_perf_event_open kernel/events/core.c:11831 [inline]
__se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723
[...]
CVE-2022-49892
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix tree mod log mishandling of reallocated nodes
We have been seeing the following panic in production
kernel BUG at fs/btrfs/tree-mod-log.c:677!
invalid opcode: 0000 [#1] SMP
RIP: 0010:tree_mod_log_rewind+0x1b4/0x200
RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293
RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000
RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00
RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001
R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00
FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
btrfs_get_old_root+0x12b/0x420
btrfs_search_old_slot+0x64/0x2f0
? tree_mod_log_oldest_root+0x3d/0xf0
resolve_indirect_ref+0xfd/0x660
? ulist_alloc+0x31/0x60
? kmem_cache_alloc_trace+0x114/0x2c0
find_parent_nodes+0x97a/0x17e0
? ulist_alloc+0x30/0x60
btrfs_find_all_roots_safe+0x97/0x150
iterate_extent_inodes+0x154/0x370
? btrfs_search_path_in_tree+0x240/0x240
iterate_inodes_from_logical+0x98/0xd0
? btrfs_search_path_in_tree+0x240/0x240
btrfs_ioctl_logical_to_ino+0xd9/0x180
btrfs_ioctl+0xe2/0x2ec0
? __mod_memcg_lruvec_state+0x3d/0x280
? do_sys_openat2+0x6d/0x140
? kretprobe_dispatcher+0x47/0x70
? kretprobe_rethook_handler+0x38/0x50
? rethook_trampoline_handler+0x82/0x140
? arch_rethook_trampoline_callback+0x3b/0x50
? kmem_cache_free+0xfb/0x270
? do_sys_openat2+0xd5/0x140
__x64_sys_ioctl+0x71/0xb0
do_syscall_64+0x2d/0x40
Which is this code in tree_mod_log_rewind()
switch (tm->op) {
case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING:
BUG_ON(tm->slot < n);
This occurs because we replay the nodes in order that they happened, and
when we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,
starting at 0. 'n' here is the number of items in this block, which in
this case was 1, but we had 2 REMOVE_WHILE_FREEING operations.
The actual root cause of this was that we were replaying operations for
a block that shouldn't have been replayed. Consider the following
sequence of events
1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().
2. We begin removing items from this root, triggering KEY_REPLACE for
it's child slots.
3. We remove one of the 2 children this root node points to, thus triggering
the root node promotion of the remaining child, and freeing this node.
4. We modify a new root, and re-allocate the above node to the root node of
this other root.
The tree mod log looks something like this
logical 0 op KEY_REPLACE (slot 1) seq 2
logical 0 op KEY_REMOVE (slot 1) seq 3
logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4
logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5
logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6
logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7
logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8
>From here the bug is triggered by the following steps
1. Call btrfs_get_old_root() on the new_root.
2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is
currently logical 0.
3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which
gives us the KEY_REPLACE seq 2, and since that's not a
LOG_ROOT_REPLACE we incorrectly believe that we don't have an old
root, because we expect that the most recent change should be a
LOG_ROOT_REPLACE.
4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE,
so we don't set old_root, we simply use our e
---truncated---
CVE-2022-49898
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Free rwi on reset success
Free the rwi structure in the event that the last rwi in the list
processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic:
retry reset if there are no other resets") introduces an issue that
results in a 32 byte memory leak whenever the last rwi in the list
gets processed.
CVE-2022-49906
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
<TASK>
dump_stack_lvl+0x7d/0xa5
dump_stack+0x15/0x1b
ubsan_epilogue+0xe/0x4e
__ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
__mdiobus_register+0x49d/0x4e0
fixed_mdio_bus_init+0xd8/0x12d
do_one_initcall+0x76/0x430
kernel_init_freeable+0x3b3/0x422
kernel_init+0x24/0x1e0
ret_from_fork+0x1f/0x30
</TASK>
CVE-2022-49907
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix inode list leak during backref walking at find_parent_nodes()
During backref walking, at find_parent_nodes(), if we are dealing with a
data extent and we get an error while resolving the indirect backrefs, at
resolve_indirect_refs(), or in the while loop that iterates over the refs
in the direct refs rbtree, we end up leaking the inode lists attached to
the direct refs we have in the direct refs rbtree that were not yet added
to the refs ulist passed as argument to find_parent_nodes(). Since they
were not yet added to the refs ulist and prelim_release() does not free
the lists, on error the caller can only free the lists attached to the
refs that were added to the refs ulist, all the remaining refs get their
inode lists never freed, therefore leaking their memory.
Fix this by having prelim_release() always free any attached inode list
to each ref found in the rbtree, and have find_parent_nodes() set the
ref's inode list to NULL once it transfers ownership of the inode list
to a ref added to the refs ulist passed to find_parent_nodes().
CVE-2022-49913
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix inode list leak during backref walking at resolve_indirect_refs()
During backref walking, at resolve_indirect_refs(), if we get an error
we jump to the 'out' label and call ulist_free() on the 'parents' ulist,
which frees all the elements in the ulist - however that does not free
any inode lists that may be attached to elements, through the 'aux' field
of a ulist node, so we end up leaking lists if we have any attached to
the unodes.
Fix this by calling free_leaf_list() instead of ulist_free() when we exit
from resolve_indirect_refs(). The static function free_leaf_list() is
moved up for this to be possible and it's slightly simplified by removing
unnecessary code.
CVE-2022-49914
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible memory leak in mISDN_register_device()
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
add put_device() to give up the reference, so that the name can be
freed in kobject_cleanup() when the refcount is 0.
Set device class before put_device() to avoid null release() function
WARN message in device_release().
CVE-2022-49915
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
<TASK>
ops_exit_list+0x125/0x170
cleanup_net+0x4ea/0xb00
process_one_work+0x9bf/0x1710
worker_thread+0x665/0x1080
kthread+0x2e4/0x3a0
ret_from_fork+0x1f/0x30
</TASK>
CVE-2022-49917
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: sched: Fix use after free in red_enqueue()
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb
len before calling child enqueue").
CVE-2022-49921
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()
nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb
should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()
will only free skb when i2c_master_send() return >=0, which means skb
will memleak when i2c_master_send() failed. Free skb no matter whether
i2c_master_send() succeeds.
CVE-2022-49922
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()
nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when
nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()
run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the
result, the skb will memleak. nxp_nci_send() should also free the skb
when nxp_nci_i2c_write() succeeds.
CVE-2022-49923
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: fdp: Fix potential memory leak in fdp_nci_send()
fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in
the function. As a result, when fdp_nci_i2c_write() finished, the skb
will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write()
finished.
CVE-2022-49924
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix null-ptr-deref in ib_core_cleanup()
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 1 PID: 379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:destroy_workqueue+0x2f/0x740
RSP: 0018:ffff888016137df8 EFLAGS: 00000202
...
Call Trace:
ib_core_cleanup+0xa/0xa1 [ib_core]
__do_sys_delete_module.constprop.0+0x34f/0x5b0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fa1a0d221b7
...
It is because the fail of roce_gid_mgmt_init() is ignored:
ib_core_init()
roce_gid_mgmt_init()
gid_cache_wq = alloc_ordered_workqueue # fail
...
ib_core_cleanup()
roce_gid_mgmt_cleanup()
destroy_workqueue(gid_cache_wq)
# destroy an unallocated wq
Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
CVE-2022-49925
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfs4: Fix kmemleak when allocate slot failed
If one of the slot allocate failed, should cleanup all the other
allocated slots, otherwise, the allocated slots will leak:
unreferenced object 0xffff8881115aa100 (size 64):
comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)
hex dump (first 32 bytes):
00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130
[<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270
[<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90
[<00000000128486db>] nfs4_init_client+0xce/0x270
[<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0
[<000000000e593b52>] nfs4_create_server+0x300/0x5f0
[<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110
[<00000000d3a6176f>] vfs_get_tree+0x41/0xf0
[<0000000016b5ad4c>] path_mount+0x9b3/0xdd0
[<00000000494cae71>] __x64_sys_mount+0x190/0x1d0
[<000000005d56bdec>] do_syscall_64+0x35/0x80
[<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2022-49927
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Correctly move list in sc_disable()
Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")
incorrectly tries to move a list from one list head to another. The
result is a kernel crash.
The crash is triggered when a link goes down and there are waiters for a
send to complete. The following signature is seen:
BUG: kernel NULL pointer dereference, address: 0000000000000030
[...]
Call Trace:
sc_disable+0x1ba/0x240 [hfi1]
pio_freeze+0x3d/0x60 [hfi1]
handle_freeze+0x27/0x1b0 [hfi1]
process_one_work+0x1b0/0x380
? process_one_work+0x380/0x380
worker_thread+0x30/0x360
? process_one_work+0x380/0x380
kthread+0xd7/0x100
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
The fix is to use the correct call to move the list.
CVE-2022-49931
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix UAF in ieee80211_scan_rx()
ieee80211_scan_rx() tries to access scan_req->flags after a
null check, but a UAF is observed when the scan is completed
and __ieee80211_scan_completed() executes, which then calls
cfg80211_scan_done() leading to the freeing of scan_req.
Since scan_req is rcu_dereference()'d, prevent the racing in
__ieee80211_scan_completed() by ensuring that from mac80211's
POV it is no longer accessed from an RCU read critical section
before we call cfg80211_scan_done().
CVE-2022-49934
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix small mempool leak in SMB2_negotiate()
In some cases of failure (dialect mismatches) in SMB2_negotiate(), after
the request is sent, the checks would return -EIO when they should be
rather setting rc = -EIO and jumping to neg_exit to free the response
buffer from mempool.
CVE-2022-49938
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
vt: Clear selection before changing the font
When changing the console font with ioctl(KDFONTOP) the new font size
can be bigger than the previous font. A previous selection may thus now
be outside of the new screen size and thus trigger out-of-bounds
accesses to graphics memory if the selection is removed in
vc_do_resize().
Prevent such out-of-memory accesses by dropping the selection before the
various con_font_set() console handlers are called.
CVE-2022-49948
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag
syzbot is reporting hung task at __input_unregister_device() [1], for
iforce_close() waiting at wait_event_interruptible() with dev->mutex held
is blocking input_disconnect_device() from __input_unregister_device().
It seems that the cause is simply that commit c2b27ef672992a20 ("Input:
iforce - wait for command completion when closing the device") forgot to
call wake_up() after clear_bit().
Fix this problem by introducing a helper that calls clear_bit() followed
by wake_up_all().
CVE-2022-49954
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kcm: fix strp_init() order and cleanup
strp_init() is called just a few lines above this csk->sk_user_data
check, it also initializes strp->work etc., therefore, it is
unnecessary to call strp_done() to cancel the freshly initialized
work.
And if sk_user_data is already used by KCM, psock->strp should not be
touched, particularly strp->work state, so we need to move strp_init()
after the csk->sk_user_data check.
This also makes a lockdep warning reported by syzbot go away.
CVE-2022-49957
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a data-race around bpf_jit_limit.
While reading bpf_jit_limit, it can be changed concurrently via sysctl,
WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit
is long, so we need to add a paired READ_ONCE() to avoid load-tearing.
CVE-2022-49967
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: clear optc underflow before turn off odm clock
[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not work.
We need to clear that before clock off.
[How]
Clear that if have when clock off.
CVE-2022-49969
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Don't redirect packets with invalid pkt_len
Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any
skbs, that is, the flow->head is null.
The root cause, as the [2] says, is because that bpf_prog_test_run_skb()
run a bpf prog which redirects empty skbs.
So we should determine whether the length of the packet modified by bpf
prog or others like bpf_prog_test is valid before forwarding it directly.
CVE-2022-49975
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
ftrace_startup does not remove ops from ftrace_ops_list when
ftrace_startup_enable fails:
register_ftrace_function
ftrace_startup
__register_ftrace_function
...
add_ftrace_ops(&ftrace_ops_list, ops)
...
...
ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1
...
return 0 // ops is in the ftrace_ops_list.
When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:
unregister_ftrace_function
ftrace_shutdown
if (unlikely(ftrace_disabled))
return -ENODEV; // return here, __unregister_ftrace_function is not executed,
// as a result, ops is still in the ftrace_ops_list
__unregister_ftrace_function
...
If ops is dynamically allocated, it will be free later, in this case,
is_ftrace_trampoline accesses NULL pointer:
is_ftrace_trampoline
ftrace_ops_trampoline
do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!
Syzkaller reports as follows:
[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b
[ 1203.508039] #PF: supervisor read access in kernel mode
[ 1203.508798] #PF: error_code(0x0000) - not-present page
[ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0
[ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI
[ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8
[ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0
[ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00
[ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246
[ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866
[ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b
[ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07
[ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399
[ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008
[ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
[ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0
[ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Therefore, when ftrace_startup_enable fails, we need to rollback registration
process and remove ops from ftrace_ops_list.
CVE-2022-49977
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: fb_pm2fb: Avoid potential divide by zero error
In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be
copied from user, then go through `fb_set_var()` and
`info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`.
Along the path, `var->pixclock` won't be modified. This function checks
whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is
zero, there will be a divide by zero error. So, it is necessary to check
whether denominator is zero to avoid crash. As this bug is found by
Syzkaller, logs are listed below.
divide error in pm2fb_check_var
Call Trace:
<TASK>
fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015
do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
CVE-2022-49978
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: Fix use-after-free Read in usb_udc_uevent()
The syzbot fuzzer found a race between uevent callbacks and gadget
driver unregistration that can cause a use-after-free bug:
---------------------------------------------------------------
BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
drivers/usb/gadget/udc/core.c:1732
Read of size 8 at addr ffff888078ce2050 by task udevd/2968
CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
06/29/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
kasan_report+0xbe/0x1f0 mm/kasan/report.c:495
usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732
dev_uevent+0x290/0x770 drivers/base/core.c:2424
---------------------------------------------------------------
The bug occurs because usb_udc_uevent() dereferences udc->driver but
does so without acquiring the udc_lock mutex, which protects this
field. If the gadget driver is unbound from the udc concurrently with
uevent processing, the driver structure may be accessed after it has
been deallocated.
To prevent the race, we make sure that the routine holds the mutex
around the racing accesses.
CVE-2022-49980
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
HID: hidraw: fix memory leak in hidraw_release()
Free the buffered reports before deleting the list entry.
BUG: memory leak
unreferenced object 0xffff88810e72f180 (size 32):
comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)
hex dump (first 32 bytes):
64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128
[<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline]
[<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521
[<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992
[<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065
[<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284
[<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670
[<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747
[<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988
[<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474
[<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline]
[<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790
[<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline]
[<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803
[<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571
[<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline]
[<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline]
[<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662
[<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106
[<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649
[<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
[<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
[<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
[<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554
CVE-2022-49981
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq
storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it
doesn't need to make forward progress under memory pressure. Marking this
workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a
non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following
warning:
[ 14.506347] ------------[ cut here ]------------
[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn
[ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130
[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu
[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun
[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130
<-snip->
[ 14.506408] Call Trace:
[ 14.506412] __flush_work+0xf1/0x1c0
[ 14.506414] __cancel_work_timer+0x12f/0x1b0
[ 14.506417] ? kernfs_put+0xf0/0x190
[ 14.506418] cancel_delayed_work_sync+0x13/0x20
[ 14.506420] disk_block_events+0x78/0x80
[ 14.506421] del_gendisk+0x3d/0x2f0
[ 14.506423] sr_remove+0x28/0x70
[ 14.506427] device_release_driver_internal+0xef/0x1c0
[ 14.506428] device_release_driver+0x12/0x20
[ 14.506429] bus_remove_device+0xe1/0x150
[ 14.506431] device_del+0x167/0x380
[ 14.506432] __scsi_remove_device+0x11d/0x150
[ 14.506433] scsi_remove_device+0x26/0x40
[ 14.506434] storvsc_remove_lun+0x40/0x60
[ 14.506436] process_one_work+0x209/0x400
[ 14.506437] worker_thread+0x34/0x400
[ 14.506439] kthread+0x121/0x140
[ 14.506440] ? process_one_work+0x400/0x400
[ 14.506441] ? kthread_park+0x90/0x90
[ 14.506443] ret_from_fork+0x35/0x40
[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---
CVE-2022-49986
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md: call __md_stop_writes in md_stop
From the link [1], we can see raid1d was running even after the path
raid_dtr -> md_stop -> __md_stop.
Let's stop write first in destructor to align with normal md-raid to
fix the KASAN issue.
[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a
CVE-2022-49987
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390: fix double free of GS and RI CBs on fork() failure
The pointers for guarded storage and runtime instrumentation control
blocks are stored in the thread_struct of the associated task. These
pointers are initially copied on fork() via arch_dup_task_struct()
and then cleared via copy_thread() before fork() returns. If fork()
happens to fail after the initial task dup and before copy_thread(),
the newly allocated task and associated thread_struct memory are
freed via free_task() -> arch_release_task_struct(). This results in
a double free of the guarded storage and runtime info structs
because the fields in the failed task still refer to memory
associated with the source task.
This problem can manifest as a BUG_ON() in set_freepointer() (with
CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)
when running trinity syscall fuzz tests on s390x. To avoid this
problem, clear the associated pointer fields in
arch_dup_task_struct() immediately after the new task is copied.
Note that the RI flag is still cleared in copy_thread() because it
resides in thread stack memory and that is where stack info is
copied.
CVE-2022-49990
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
loop: Check for overflow while configuring loop
The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.
loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).
The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
lo->lo_offset = info->lo_offset;
This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
WARN_ON_ONCE(iter->iomap.offset > iter->pos);
Thus, check for negative value during loop_set_status_from_info().
Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
CVE-2022-49993
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix refcount leak in __xfrm_policy_check()
The issue happens on an error path in __xfrm_policy_check(). When the
fetching process of the object `pols[1]` fails, the function simply
returns 0, forgetting to decrement the reference count of `pols[0]`,
which is incremented earlier by either xfrm_sk_policy_lookup() or
xfrm_policy_lookup(). This may result in memory leaks.
Fix it by decreasing the reference count of `pols[0]` in that path.
CVE-2022-50007
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kprobes: don't call disarm_kprobe() for disabled kprobes
The assumption in __disable_kprobe() is wrong, and it could try to disarm
an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can
easily reproduce this issue.
1. Write 0 to /sys/kernel/debug/kprobes/enabled.
# echo 0 > /sys/kernel/debug/kprobes/enabled
2. Run execsnoop. At this time, one kprobe is disabled.
# /usr/share/bcc/tools/execsnoop &
[1] 2460
PCOMM PID PPID RET ARGS
# cat /sys/kernel/debug/kprobes/list
ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]
ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes
kprobes_all_disarmed to false but does not arm the disabled kprobe.
# echo 1 > /sys/kernel/debug/kprobes/enabled
# cat /sys/kernel/debug/kprobes/list
ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]
ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the
disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().
# fg
/usr/share/bcc/tools/execsnoop
^C
Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses
some cleanups and leaves the aggregated kprobe in the hash table. Then,
__unregister_trace_kprobe() initialises tk->rp.kp.list and creates an
infinite loop like this.
aggregated kprobe.list -> kprobe.list -.
^ |
'.__.'
In this situation, these commands fall into the infinite loop and result
in RCU stall or soft lockup.
cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the
infinite loop with RCU.
/usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex,
and __get_valid_kprobe() is stuck in
the loop.
To avoid the issue, make sure we don't call disarm_kprobe() for disabled
kprobes.
[0]
Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2)
WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)
Modules linked in: ena
CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28
Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017
RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)
Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94
RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001
RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff
RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff
R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40
R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000
FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
__disable_kprobe (kernel/kprobes.c:1716)
disable_kprobe (kernel/kprobes.c:2392)
__disable_trace_kprobe (kernel/trace/trace_kprobe.c:340)
disable_trace_kprobe (kernel/trace/trace_kprobe.c:429)
perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168)
perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295)
_free_event (kernel/events/core.c:4971)
perf_event_release_kernel (kernel/events/core.c:5176)
perf_release (kernel/events/core.c:5186)
__fput (fs/file_table.c:321)
task_work_run (./include/linux/
---truncated---
CVE-2022-50008
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64: Init jump labels before parse_early_param()
On 64-bit, calling jump_label_init() in setup_feature_keys() is too
late because static keys may be used in subroutines of
parse_early_param() which is again subroutine of early_init_devtree().
For example booting with "threadirqs":
static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init()
WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120
...
NIP static_key_enable_cpuslocked+0xfc/0x120
LR static_key_enable_cpuslocked+0xf8/0x120
Call Trace:
static_key_enable_cpuslocked+0xf8/0x120 (unreliable)
static_key_enable+0x30/0x50
setup_forced_irqthreads+0x28/0x40
do_early_param+0xa0/0x108
parse_args+0x290/0x4e0
parse_early_options+0x48/0x5c
parse_early_param+0x58/0x84
early_init_devtree+0xd4/0x518
early_setup+0xb4/0x214
So call jump_label_init() just before parse_early_param() in
early_init_devtree().
[mpe: Add call trace to change log and minor wording edits.]
CVE-2022-50012
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid resizing to a partial cluster size
This patch avoids an attempt to resize the filesystem to an
unaligned cluster boundary. An online resize to a size that is not
integral to cluster size results in the last iteration attempting to
grow the fs by a negative amount, which trips a BUG_ON and leaves the fs
with a corrupted in-memory superblock.
CVE-2022-50020
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers:md:fix a potential use-after-free bug
In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and
may cause sh to be released. However, sh is subsequently used in lines
2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an
use-after-free bug.
It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of
the function.
CVE-2022-50022
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cxl: Fix a memory leak in an error handling path
A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the
error handling path of afu_allocate_irqs().
CVE-2022-50025
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE
There is no corresponding free routine if lpfc_sli4_issue_wqe fails to
issue the CMF WQE in lpfc_issue_cmf_sync_wqe.
If ret_val is non-zero, then free the iocbq request structure.
CVE-2022-50027
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input
Malformed user input to debugfs results in buffer overflow crashes. Adapt
input string lengths to fit within internal buffers, leaving space for NULL
terminators.
CVE-2022-50030
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: host: ohci-ppc-of: Fix refcount leak bug
In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return
a node pointer with refcount incremented. We should use of_node_put()
when it is not used anymore.
CVE-2022-50033
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pci: Fix get_phb_number() locking
The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP
warning on some systems:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
1 lock held by swapper/1:
#0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220
Preemption disabled at:
[<00000000>] 0x0
CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1
Call Trace:
[d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)
[d101dcb0] [c0093b70] __might_resched+0x258/0x2a8
[d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec
[d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4
[d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220
[d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784
[d101de50] [c140852c] discover_phbs+0x30/0x4c
[d101de60] [c0007fd4] do_one_initcall+0x94/0x344
[d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c
[d101df10] [c00086e0] kernel_init+0x34/0x160
[d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64
This is because pcibios_alloc_controller() holds hose_spinlock but
of_alias_get_id() takes of_mutex which can sleep.
The hose_spinlock protects the phb_bitmap, and also the hose_list, but
it doesn't need to be held while get_phb_number() calls the OF routines,
because those are only looking up information in the device tree.
So fix it by having get_phb_number() take the hose_spinlock itself, only
where required, and then dropping the lock before returning.
pcibios_alloc_controller() then needs to take the lock again before the
list_add() but that's safe, the order of the list is not important.
CVE-2022-50045
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix adminq error handling
iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent
memory for VF mailbox.
Free DMA regions for both ASQ and ARQ in case error happens during
configuration of ASQ/ARQ registers.
Without this change it is possible to see when unloading interface:
74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32]
One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
CVE-2022-50055
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix memory leak inside XPD_TX with mergeable
When we call xdp_convert_buff_to_frame() to get xdpf, if it returns
NULL, we should check if xdp_page was allocated by xdp_linearize_page().
If it is newly allocated, it should be freed here alone. Just like any
other "goto err_xdp".
CVE-2022-50065
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: fix aq_vec index out of range error
The final update statement of the for loop exceeds the array range, the
dereference of self->aq_vec[i] is not checked and then leads to the
index out of range error.
Also fixed this kind of coding style in other for loop.
[ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48
[ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]'
[ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2
[ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022
[ 97.937611] Workqueue: events_unbound async_run_entry_fn
[ 97.937616] Call Trace:
[ 97.937617] <TASK>
[ 97.937619] dump_stack_lvl+0x49/0x63
[ 97.937624] dump_stack+0x10/0x16
[ 97.937626] ubsan_epilogue+0x9/0x3f
[ 97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49
[ 97.937629] ? __scm_send+0x348/0x440
[ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic]
[ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic]
[ 97.937644] aq_suspend_common+0x88/0x90 [atlantic]
[ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic]
[ 97.937653] pci_pm_suspend+0x7e/0x1a0
[ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0
[ 97.937657] dpm_run_callback+0x54/0x190
[ 97.937660] __device_suspend+0x14c/0x4d0
[ 97.937661] async_suspend+0x23/0x70
[ 97.937663] async_run_entry_fn+0x33/0x120
[ 97.937664] process_one_work+0x21f/0x3f0
[ 97.937666] worker_thread+0x4a/0x3c0
[ 97.937668] ? process_one_work+0x3f0/0x3f0
[ 97.937669] kthread+0xf0/0x120
[ 97.937671] ? kthread_complete_and_exit+0x20/0x20
[ 97.937672] ret_from_fork+0x22/0x30
[ 97.937676] </TASK>
v2. fixed "warning: variable 'aq_vec' set but not used"
v3. simplified a for loop
CVE-2022-50066
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null
Fixes a NULL pointer derefence bug triggered from tap driver.
When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null
(in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb)
virtio_net_hdr_to_skb calls dev_parse_header_protocol which
needs skb->dev field to be valid.
The line that trigers the bug is in dev_parse_header_protocol
(dev is at offset 0x10 from skb and is stored in RAX register)
if (!dev->header_ops || !dev->header_ops->parse_protocol)
22e1: mov 0x10(%rbx),%rax
22e5: mov 0x230(%rax),%rax
Setting skb->dev before the call in tap.c fixes the issue.
BUG: kernel NULL pointer dereference, address: 0000000000000230
RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]
Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48
RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010
RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300
RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8
R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6
FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0
Call Trace:
tap_get_user+0x3f1/0x540 [tap]
tap_sendmsg+0x56/0x362 [tap]
? get_tx_bufs+0xc2/0x1e0 [vhost_net]
handle_tx_copy+0x114/0x670 [vhost_net]
handle_tx+0xb0/0xe0 [vhost_net]
handle_tx_kick+0x15/0x20 [vhost_net]
vhost_worker+0x7b/0xc0 [vhost]
? vhost_vring_call_reset+0x40/0x40 [vhost]
kthread+0xfa/0x120
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
CVE-2022-50073
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tee: add overflow check in register_shm_helper()
With special lengths supplied by user space, register_shm_helper() has
an integer overflow when calculating the number of pages covered by a
supplied user space memory region.
This causes internal_get_user_pages_fast() a helper function of
pin_user_pages_fast() to do a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
Modules linked in:
CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
pc : internal_get_user_pages_fast+0x474/0xa80
Call trace:
internal_get_user_pages_fast+0x474/0xa80
pin_user_pages_fast+0x24/0x4c
register_shm_helper+0x194/0x330
tee_shm_register_user_buf+0x78/0x120
tee_ioctl+0xd0/0x11a0
__arm64_sys_ioctl+0xa8/0xec
invoke_syscall+0x48/0x114
Fix this by adding an an explicit call to access_ok() in
tee_shm_register_user_buf() to catch an invalid user space address
early.
CVE-2022-50080
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in ext4_iomap_begin as race between bmap and write
We got issue as follows:
------------[ cut here ]------------
WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0
RIP: 0010:ext4_iomap_begin+0x182/0x5d0
RSP: 0018:ffff88812460fa08 EFLAGS: 00010293
RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f
R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001
R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee
FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
iomap_apply+0x119/0x570
iomap_bmap+0x124/0x150
ext4_bmap+0x14f/0x250
bmap+0x55/0x80
do_vfs_ioctl+0x952/0xbd0
__x64_sys_ioctl+0xc6/0x170
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Above issue may happen as follows:
bmap write
bmap
ext4_bmap
iomap_bmap
ext4_iomap_begin
ext4_file_write_iter
ext4_buffered_write_iter
generic_perform_write
ext4_da_write_begin
ext4_da_write_inline_data_begin
ext4_prepare_inline_data
ext4_create_inline_data
ext4_set_inode_flag(inode,
EXT4_INODE_INLINE_DATA);
if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on
To solved above issue hold inode lock in ext4_bamp.
CVE-2022-50082
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2022-50083
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm raid: fix address sanitizer warning in raid_status
There is this warning when using a kernel with the address sanitizer
and running this testsuite:
https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid
==================================================================
BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
<TASK>
dump_stack_lvl+0x6a/0x9c
print_address_description.constprop.0+0x1f/0x1e0
print_report.cold+0x55/0x244
kasan_report+0xc9/0x100
raid_status+0x1747/0x2820 [dm_raid]
dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]
table_load+0x35c/0x630 [dm_mod]
ctl_ioctl+0x411/0x630 [dm_mod]
dm_ctl_ioctl+0xa/0x10 [dm_mod]
__x64_sys_ioctl+0x12a/0x1a0
do_syscall_64+0x5b/0x80
The warning is caused by reading conf->max_nr_stripes in raid_status. The
code in raid_status reads mddev->private, casts it to struct r5conf and
reads the entry max_nr_stripes.
However, if we have different raid type than 4/5/6, mddev->private
doesn't point to struct r5conf; it may point to struct r0conf, struct
r1conf, struct r10conf or struct mpconf. If we cast a pointer to one
of these structs to struct r5conf, we will be reading invalid memory
and KASAN warns about it.
Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.
CVE-2022-50084
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm raid: fix address sanitizer warning in raid_resume
There is a KASAN warning in raid_resume when running the lvm test
lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks
is greater than rs->raid_disks, so the loop touches one entry beyond
the allocated length.
CVE-2022-50085
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails
When scpi probe fails, at any point, we need to ensure that the scpi_info
is not set and will remain NULL until the probe succeeds. If it is not
taken care, then it could result use-after-free as the value is exported
via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()
but freed when the probe fails.
CVE-2022-50087
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
locking/csd_lock: Change csdlock_debug from early_param to __setup
The csdlock_debug kernel-boot parameter is parsed by the
early_param() function csdlock_debug(). If set, csdlock_debug()
invokes static_branch_enable() to enable csd_lock_wait feature, which
triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and
CONFIG_SPARSEMEM_VMEMMAP=n.
With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in
static_key_enable() and returns NULL, resulting in a NULL dereference
because mem_section is initialized only later in sparse_init().
This is also a problem for powerpc because early_param() functions
are invoked earlier than jump_label_init(), also resulting in
static_key_enable() failures. These failures cause the warning "static
key 'xxx' used before call to jump_label_init()".
Thus, early_param is too early for csd_lock_wait to run
static_branch_enable(), so changes it to __setup to fix these.
CVE-2022-50091
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm thin: fix use-after-free crash in dm_sm_register_threshold_callback
Fault inject on pool metadata device reports:
BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80
Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950
CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_address_description.constprop.0.cold+0xeb/0x3f4
kasan_report.cold+0xe6/0x147
dm_pool_register_metadata_threshold+0x40/0x80
pool_ctr+0xa0a/0x1150
dm_table_add_target+0x2c8/0x640
table_load+0x1fd/0x430
ctl_ioctl+0x2c4/0x5a0
dm_ctl_ioctl+0xa/0x10
__x64_sys_ioctl+0xb3/0xd0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
This can be easily reproduced using:
echo offline > /sys/block/sda/device/state
dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10
dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0"
If a metadata commit fails, the transaction will be aborted and the
metadata space maps will be destroyed. If a DM table reload then
happens for this failed thin-pool, a use-after-free will occur in
dm_sm_register_threshold_callback (called from
dm_pool_register_metadata_threshold).
Fix this by in dm_pool_register_metadata_threshold() by returning the
-EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()
with a new error message: "Error registering metadata threshold".
CVE-2022-50092
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)
KASAN reports:
[ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
[ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0
[ 4.683454][ T0]
[ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1
[ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016
[ 4.703196][ T0] Call Trace:
[ 4.706334][ T0] <TASK>
[ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
after converting the type of the first argument (@nr, bit number)
of arch_test_bit() from `long` to `unsigned long`[0].
Under certain conditions (for example, when ACPI NUMA is disabled
via command line), pxm_to_node() can return %NUMA_NO_NODE (-1).
It is valid 'magic' number of NUMA node, but not valid bit number
to use in bitops.
node_online() eventually descends to test_bit() without checking
for the input, assuming it's on caller side (which might be good
for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads
to an insane array index when calculating bit position in memory.
For now, add an explicit check for @node being not %NUMA_NO_NODE
before calling test_bit(). The actual logics didn't change here
at all.
[0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d
CVE-2022-50093
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
spmi: trace: fix stack-out-of-bound access in SPMI tracing functions
trace_spmi_write_begin() and trace_spmi_read_end() both call
memcpy() with a length of "len + 1". This leads to one extra
byte being read beyond the end of the specified buffer. Fix
this out-of-bound memory access by using a length of "len"
instead.
Here is a KASAN log showing the issue:
BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
...
Call trace:
dump_backtrace+0x0/0x3e8
show_stack+0x2c/0x3c
dump_stack_lvl+0xdc/0x11c
print_address_description+0x74/0x384
kasan_report+0x188/0x268
kasan_check_range+0x270/0x2b0
memcpy+0x90/0xe8
trace_event_raw_event_spmi_read_end+0x1d0/0x234
spmi_read_cmd+0x294/0x3ac
spmi_ext_register_readl+0x84/0x9c
regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
_regmap_raw_read+0x40c/0x754
regmap_raw_read+0x3a0/0x514
regmap_bulk_read+0x418/0x494
adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
...
__arm64_sys_read+0x4c/0x60
invoke_syscall+0x80/0x218
el0_svc_common+0xec/0x1c8
...
addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]
this frame has 1 object:
[32, 33) 'status'
Memory state around the buggy address:
ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00
^
ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00
==================================================================
CVE-2022-50094
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: s3fb: Check the size of screen before memset_io()
In the function s3fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000
[ 54.083742] #PF: supervisor write access in kernel mode
[ 54.083744] #PF: error_code(0x0002) - not-present page
[ 54.083760] RIP: 0010:memset_orig+0x33/0xb0
[ 54.083782] Call Trace:
[ 54.083788] s3fb_set_par+0x1ec6/0x4040
[ 54.083806] fb_set_var+0x604/0xeb0
[ 54.083836] do_fb_ioctl+0x234/0x670
Fix the this by checking the value of 'screen_size' before memset_io().
CVE-2022-50097
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts
Ensure SRB is returned during I/O timeout error escalation. If that is not
possible fail the escalation path.
Following crash stack was seen:
BUG: unable to handle kernel paging request at 0000002f56aa90f8
IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]
Call Trace:
? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]
? qla2x00_start_sp+0x116/0x1170 [qla2xxx]
? dma_pool_alloc+0x1d6/0x210
? mempool_alloc+0x54/0x130
? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]
? qla_do_work+0x2d/0x40 [qla2xxx]
? process_one_work+0x14c/0x390
CVE-2022-50098
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: arkfb: Check the size of screen before memset_io()
In the function arkfb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000
[ 659.399077] #PF: supervisor write access in kernel mode
[ 659.399079] #PF: error_code(0x0002) - not-present page
[ 659.399094] RIP: 0010:memset_orig+0x33/0xb0
[ 659.399116] Call Trace:
[ 659.399122] arkfb_set_par+0x143f/0x24c0
[ 659.399130] fb_set_var+0x604/0xeb0
[ 659.399161] do_fb_ioctl+0x234/0x670
[ 659.399189] fb_ioctl+0xdd/0x130
Fix the this by checking the value of 'screen_size' before memset_io().
CVE-2022-50099
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: vt8623fb: Check the size of screen before memset_io()
In the function vt8623fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000
[ 583.339049] #PF: supervisor write access in kernel mode
[ 583.339052] #PF: error_code(0x0002) - not-present page
[ 583.339074] RIP: 0010:memset_orig+0x33/0xb0
[ 583.339110] Call Trace:
[ 583.339118] vt8623fb_set_par+0x11cd/0x21e0
[ 583.339146] fb_set_var+0x604/0xeb0
[ 583.339181] do_fb_ioctl+0x234/0x670
[ 583.339209] fb_ioctl+0xdd/0x130
Fix the this by checking the value of 'screen_size' before memset_io().
CVE-2022-50101
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock()
Since the user can control the arguments of the ioctl() from the user
space, under special arguments that may result in a divide-by-zero bug
in:
drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul);
with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0.
and then in:
drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock);
we'll get a division-by-zero.
The following log can reveal it:
divide error: 0000 [#1] PREEMPT SMP KASAN PTI
RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline]
RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784
Call Trace:
fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034
do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
Fix this by checking the argument of ark_set_pixclock() first.
CVE-2022-50102
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed
With cgroup v2, the cpuset's cpus_allowed mask can be empty indicating
that the cpuset will just use the effective CPUs of its parent. So
cpuset_can_attach() can call task_can_attach() with an empty mask.
This can lead to cpumask_any_and() returns nr_cpu_ids causing the call
to dl_bw_of() to crash due to percpu value access of an out of bound
CPU value. For example:
[80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0
:
[80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0
:
[80468.207946] Call Trace:
[80468.208947] cpuset_can_attach+0xa0/0x140
[80468.209953] cgroup_migrate_execute+0x8c/0x490
[80468.210931] cgroup_update_dfl_csses+0x254/0x270
[80468.211898] cgroup_subtree_control_write+0x322/0x400
[80468.212854] kernfs_fop_write_iter+0x11c/0x1b0
[80468.213777] new_sync_write+0x11f/0x1b0
[80468.214689] vfs_write+0x1eb/0x280
[80468.215592] ksys_write+0x5f/0xe0
[80468.216463] do_syscall_64+0x5c/0x80
[80468.224287] entry_SYSCALL_64_after_hwframe+0x44/0xae
Fix that by using effective_cpus instead. For cgroup v1, effective_cpus
is the same as cpus_allowed. For v2, effective_cpus is the real cpumask
to be used by tasks within the cpuset anyway.
Also update task_can_attach()'s 2nd argument name to cs_effective_cpus to
reflect the change. In addition, a check is added to task_can_attach()
to guard against the possibility that cpumask_any_and() may return a
value >= nr_cpu_ids.
CVE-2022-50103
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive: Fix refcount leak in xive_get_max_prio
of_find_node_by_path() returns a node pointer with
refcount incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-50104
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: amba-clcd: Fix refcount leak bugs
In clcdfb_of_init_display(), we should call of_node_put() for the
references returned by of_graph_get_next_endpoint() and
of_graph_get_remote_port_parent() which have increased the refcount.
Besides, we should call of_node_put() both in fail path or when
the references are not used anymore.
CVE-2022-50109
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix deadlock and link starvation in outgoing data path
The current implementation queues up new control and user packets as needed
and processes this queue down to the ldisc in the same code path.
That means that the upper and the lower layer are hard coupled in the code.
Due to this deadlocks can happen as seen below while transmitting data,
especially during ldisc congestion. Furthermore, the data channels starve
the control channel on high transmission load on the ldisc.
Introduce an additional control channel data queue to prevent timeouts and
link hangups during ldisc congestion. This is being processed before the
user channel data queue in gsm_data_kick(), i.e. with the highest priority.
Put the queue to ldisc data path into a workqueue and trigger it whenever
new data has been put into the transmission queue. Change
gsm_dlci_data_sweep() accordingly to fill up the transmission queue until
TX_THRESH_HI. This solves the locking issue, keeps latency low and provides
good performance on high data load.
Note that now all packets from a DLCI are removed from the internal queue
if the associated DLCI was closed. This ensures that no data is sent by the
introduced write task to an already closed DLCI.
BUG: spinlock recursion on CPU#0, test_v24_loop/124
lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0
CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0x34/0x44
do_raw_spin_lock+0x76/0xa0
_raw_spin_lock_irqsave+0x72/0x80
uart_write_room+0x3b/0xc0
gsm_data_kick+0x14b/0x240 [n_gsm]
gsmld_write_wakeup+0x35/0x70 [n_gsm]
tty_wakeup+0x53/0x60
tty_port_default_wakeup+0x1b/0x30
serial8250_tx_chars+0x12f/0x220
serial8250_handle_irq.part.0+0xfe/0x150
serial8250_default_handle_irq+0x48/0x80
serial8250_interrupt+0x56/0xa0
__handle_irq_event_percpu+0x78/0x1f0
handle_irq_event+0x34/0x70
handle_fasteoi_irq+0x90/0x1e0
__common_interrupt+0x69/0x100
common_interrupt+0x48/0xc0
asm_common_interrupt+0x1e/0x40
RIP: 0010:__do_softirq+0x83/0x34e
Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d
e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61
80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00
RSP: 0018:ffffc90000003f98 EFLAGS: 00000286
RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7
RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000
? __do_softirq+0x73/0x34e
irq_exit_rcu+0xb5/0x100
common_interrupt+0xa4/0xc0
</IRQ>
<TASK>
asm_common_interrupt+0x1e/0x40
RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50
Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff
48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 <e8> 3d 97 33 ff
65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44
RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202
RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000
RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001
RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8
? _raw_spin_unlock_irqrestore+0x23/0x50
gsmtty_write+0x65/0x80 [n_gsm]
n_tty_write+0x33f/0x530
? swake_up_all+0xe0/0xe0
file_tty_write.constprop.0+0x1b1/0x320
? n_tty_flush_buffer+0xb0/0xb0
new_sync_write+0x10c/0x190
vfs_write+0x282/0x310
ksys_write+0x68/0xe0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f3e5e35c15c
Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24
---truncated---
CVE-2022-50116
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted
Following process will fail assertion 'jh->b_frozen_data == NULL' in
jbd2_journal_dirty_metadata():
jbd2_journal_commit_transaction
unlink(dir/a)
jh->b_transaction = trans1
jh->b_jlist = BJ_Metadata
journal->j_running_transaction = NULL
trans1->t_state = T_COMMIT
unlink(dir/b)
handle->h_trans = trans2
do_get_write_access
jh->b_modified = 0
jh->b_frozen_data = frozen_buffer
jh->b_next_transaction = trans2
jbd2_journal_dirty_metadata
is_handle_aborted
is_journal_aborted // return false
--> jbd2 abort <--
while (commit_transaction->t_buffers)
if (is_journal_aborted)
jbd2_journal_refile_buffer
__jbd2_journal_refile_buffer
WRITE_ONCE(jh->b_transaction,
jh->b_next_transaction)
WRITE_ONCE(jh->b_next_transaction, NULL)
__jbd2_journal_file_buffer(jh, BJ_Reserved)
J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure !
The reproducer (See detail in [Link]) reports:
------------[ cut here ]------------
kernel BUG at fs/jbd2/transaction.c:1629!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 584 Comm: unlink Tainted: G W
5.19.0-rc6-00115-g4a57a8400075-dirty #697
RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470
RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202
Call Trace:
<TASK>
__ext4_handle_dirty_metadata+0xa0/0x290
ext4_handle_dirty_dirblock+0x10c/0x1d0
ext4_delete_entry+0x104/0x200
__ext4_unlink+0x22b/0x360
ext4_unlink+0x275/0x390
vfs_unlink+0x20b/0x4c0
do_unlinkat+0x42f/0x4c0
__x64_sys_unlink+0x37/0x50
do_syscall_64+0x35/0x80
After journal aborting, __jbd2_journal_refile_buffer() is executed with
holding @jh->b_state_lock, we can fix it by moving 'is_handle_aborted()'
into the area protected by @jh->b_state_lock.
CVE-2022-50126
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix error unwind in rxe_create_qp()
In the function rxe_create_qp(), rxe_qp_from_init() is called to
initialize qp, internally things like the spin locks are not setup until
rxe_qp_init_req().
If an error occures before this point then the unwind will call
rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()
which will oops when trying to access the uninitialized spinlock.
Move the spinlock initializations earlier before any failures.
CVE-2022-50127
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: fix potential memory leak in setup_base_ctxt()
setup_base_ctxt() allocates a memory chunk for uctxt->groups with
hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups
is not released, which will lead to a memory leak.
We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups()
when init_user_ctxt() fails.
CVE-2022-50134
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr()
__qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with
init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr"
is released while "mr->info.pbl_table" is not released, which will lead
to a memory leak.
We should release the "mr->info.pbl_table" with qedr_free_pbl() when error
occurs to fix the memory leak.
CVE-2022-50138
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch
of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
of_node_put() checks null pointer.
CVE-2022-50141
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors
If dw_pcie_ep_init() fails to perform any action after the EPC memory is
initialized and the MSI memory region is allocated, the latter parts won't
be undone thus causing a memory leak. Add a cleanup-on-error path to fix
these leaks.
[bhelgaas: commit log]
CVE-2022-50146
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
In __driver_attach function, The lock holding logic is as follows:
...
__driver_attach
if (driver_allows_async_probing(drv))
device_lock(dev) // get lock dev
async_schedule_dev(__driver_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__driver_attach_async_helper will get lock dev as
will, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like
below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:
0 flags:0x00004000
[ 370.788865] Call Trace:
[ 370.789374] <TASK>
[ 370.789841] __schedule+0x482/0x1050
[ 370.790613] schedule+0x92/0x1a0
[ 370.791290] schedule_preempt_disabled+0x2c/0x50
[ 370.792256] __mutex_lock.isra.0+0x757/0xec0
[ 370.793158] __mutex_lock_slowpath+0x1f/0x30
[ 370.794079] mutex_lock+0x50/0x60
[ 370.794795] __device_driver_lock+0x2f/0x70
[ 370.795677] ? driver_probe_device+0xd0/0xd0
[ 370.796576] __driver_attach_async_helper+0x1d/0xd0
[ 370.797318] ? driver_probe_device+0xd0/0xd0
[ 370.797957] async_schedule_node_domain+0xa5/0xc0
[ 370.798652] async_schedule_node+0x19/0x30
[ 370.799243] __driver_attach+0x246/0x290
[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0
[ 370.800548] bus_for_each_dev+0x9d/0x130
[ 370.801132] driver_attach+0x22/0x30
[ 370.801666] bus_add_driver+0x290/0x340
[ 370.802246] driver_register+0x88/0x140
[ 370.802817] ? virtio_scsi_init+0x116/0x116
[ 370.803425] scsi_register_driver+0x1a/0x30
[ 370.804057] init_sd+0x184/0x226
[ 370.804533] do_one_initcall+0x71/0x3a0
[ 370.805107] kernel_init_freeable+0x39a/0x43a
[ 370.805759] ? rest_init+0x150/0x150
[ 370.806283] kernel_init+0x26/0x230
[ 370.806799] ret_from_fork+0x1f/0x30
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
CVE-2022-50149
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-50152
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe
of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-50153
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
of: check previous kernel's ima-kexec-buffer against memory bounds
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:
$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
<snip>
BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
Faulting instruction address: 0xc000000000837974
Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
Call Trace:
[c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
[c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
[c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
[c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
[c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
[c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
[c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010
---[ end trace 0000000000000000 ]---
Fix this issue by checking returned PFN range of previous kernel's
ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.
CVE-2022-50159
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: Fix possible refcount leak in if_usb_probe()
usb_get_dev will be called before lbs_get_firmware_async which means that
usb_put_dev need to be called when lbs_get_firmware_async fails.
CVE-2022-50162
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Fix global state lock backoff
We need to grab the lock after the early return for !hwpipe case.
Otherwise, we could have hit contention yet still returned 0.
Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged
in CI:
WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154
Modules linked in:
CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1
Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_modeset_lock+0xf8/0x154
lr : drm_atomic_get_private_obj_state+0x84/0x170
sp : ffff80000cfab6a0
x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00
x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58
x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001
x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038
x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0
x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47
x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610
x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000
x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029
x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58
Call trace:
drm_modeset_lock+0xf8/0x154
drm_atomic_get_private_obj_state+0x84/0x170
mdp5_get_global_state+0x54/0x6c
mdp5_pipe_release+0x2c/0xd4
mdp5_plane_atomic_check+0x2ec/0x414
drm_atomic_helper_check_planes+0xd8/0x210
drm_atomic_helper_check+0x54/0xb0
...
---[ end trace 0000000000000000 ]---
drm_modeset_lock attempting to lock a contended lock without backoff:
drm_modeset_lock+0x148/0x154
mdp5_get_global_state+0x30/0x6c
mdp5_pipe_release+0x2c/0xd4
mdp5_plane_atomic_check+0x290/0x414
drm_atomic_helper_check_planes+0xd8/0x210
drm_atomic_helper_check+0x54/0xb0
drm_atomic_check_only+0x4b0/0x8f4
drm_atomic_commit+0x68/0xe0
Patchwork: https://patchwork.freedesktop.org/patch/492701/
CVE-2022-50173
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
virtio-gpu: fix a missing check to avoid NULL dereference
'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset()
and it will lead to a NULL dereference by a lately use of it
(i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check.
[ kraxel: minor codestyle fixup ]
CVE-2022-50181
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()
The last case label can write two buffers 'mc_reg_address[j]' and
'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE
since there are no checks for this value in both case labels after the
last 'j++'.
Instead of changing '>' to '>=' there, add the bounds check at the start
of the second 'case' (the first one already has it).
Also, remove redundant last checks for 'j' index bigger than array size.
The expression is always false. Moreover, before or after the patch
'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it
seems it can be a valid value.
Detected using the static analysis tool - Svace.
CVE-2022-50185
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
regulator: of: Fix refcount leak bug in of_get_regulation_constraints()
We should call the of_node_put() for the reference returned by
of_get_child_by_name() which has increased the refcount.
CVE-2022-50191
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
selinux: Add boundary check in put_entry()
Just like next_entry(), boundary check is necessary to prevent memory
out-of-bound access.
CVE-2022-50200
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
arm64: fix oops in concurrently setting insn_emulation sysctls
emulation_proc_handler() changes table->data for proc_dointvec_minmax
and can generate the following Oops if called concurrently with itself:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
| Internal error: Oops: 96000006 [#1] SMP
| Call trace:
| update_insn_emulation_mode+0xc0/0x148
| emulation_proc_handler+0x64/0xb8
| proc_sys_call_handler+0x9c/0xf8
| proc_sys_write+0x18/0x20
| __vfs_write+0x20/0x48
| vfs_write+0xe4/0x1d0
| ksys_write+0x70/0xf8
| __arm64_sys_write+0x20/0x28
| el0_svc_common.constprop.0+0x7c/0x1c0
| el0_svc_handler+0x2c/0xa0
| el0_svc+0x8/0x200
To fix this issue, keep the table->data as &insn->current_mode and
use container_of() to retrieve the insn pointer. Another mutex is
used to protect against the current_mode update but not for retrieving
insn_emulation as table->data is no longer changing.
CVE-2022-50206
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md-raid10: fix KASAN warning
There's a KASAN warning in raid10_remove_disk when running the lvm
test lvconvert-raid-reshape.sh. We fix this warning by verifying that the
value "number" is valid.
BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682
CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_report.cold+0x45/0x57a
? __lock_text_start+0x18/0x18
? raid10_remove_disk+0x61/0x2a0 [raid10]
kasan_report+0xa8/0xe0
? raid10_remove_disk+0x61/0x2a0 [raid10]
raid10_remove_disk+0x61/0x2a0 [raid10]
Buffer I/O error on dev dm-76, logical block 15344, async page read
? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0
remove_and_add_spares+0x367/0x8a0 [md_mod]
? super_written+0x1c0/0x1c0 [md_mod]
? mutex_trylock+0xac/0x120
? _raw_spin_lock+0x72/0xc0
? _raw_spin_lock_bh+0xc0/0xc0
md_check_recovery+0x848/0x960 [md_mod]
raid10d+0xcf/0x3360 [raid10]
? sched_clock_cpu+0x185/0x1a0
? rb_erase+0x4d4/0x620
? var_wake_function+0xe0/0xe0
? psi_group_change+0x411/0x500
? preempt_count_sub+0xf/0xc0
? _raw_spin_lock_irqsave+0x78/0xc0
? __lock_text_start+0x18/0x18
? raid10_sync_request+0x36c0/0x36c0 [raid10]
? preempt_count_sub+0xf/0xc0
? _raw_spin_unlock_irqrestore+0x19/0x40
? del_timer_sync+0xa9/0x100
? try_to_del_timer_sync+0xc0/0xc0
? _raw_spin_lock_irqsave+0x78/0xc0
? __lock_text_start+0x18/0x18
? _raw_spin_unlock_irq+0x11/0x24
? __list_del_entry_valid+0x68/0xa0
? finish_wait+0xa3/0x100
md_thread+0x161/0x260 [md_mod]
? unregister_md_personality+0xa0/0xa0 [md_mod]
? _raw_spin_lock_irqsave+0x78/0xc0
? prepare_to_wait_event+0x2c0/0x2c0
? unregister_md_personality+0xa0/0xa0 [md_mod]
kthread+0x148/0x180
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 124495:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x80/0xa0
setup_conf+0x140/0x5c0 [raid10]
raid10_run+0x4cd/0x740 [raid10]
md_run+0x6f9/0x1300 [md_mod]
raid_ctr+0x2531/0x4ac0 [dm_raid]
dm_table_add_target+0x2b0/0x620 [dm_mod]
table_load+0x1c8/0x400 [dm_mod]
ctl_ioctl+0x29e/0x560 [dm_mod]
dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
__do_compat_sys_ioctl+0xfa/0x160
do_syscall_64+0x90/0xc0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Last potentially related work creation:
kasan_save_stack+0x1e/0x40
__kasan_record_aux_stack+0x9e/0xc0
kvfree_call_rcu+0x84/0x480
timerfd_release+0x82/0x140
L __fput+0xfa/0x400
task_work_run+0x80/0xc0
exit_to_user_mode_prepare+0x155/0x160
syscall_exit_to_user_mode+0x12/0x40
do_syscall_64+0x42/0xc0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Second to last potentially related work creation:
kasan_save_stack+0x1e/0x40
__kasan_record_aux_stack+0x9e/0xc0
kvfree_call_rcu+0x84/0x480
timerfd_release+0x82/0x140
__fput+0xfa/0x400
task_work_run+0x80/0xc0
exit_to_user_mode_prepare+0x155/0x160
syscall_exit_to_user_mode+0x12/0x40
do_syscall_64+0x42/0xc0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The buggy address belongs to the object at ffff889108f3d200
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
256-byte region [ffff889108f3d200, ffff889108f3d300)
The buggy address belongs to the physical page:
page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c
head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0
flags: 0x4000000000010200(slab|head|zone=2)
raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40
raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff889108f3d280: 00 00
---truncated---
CVE-2022-50211
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Allow waiting for commands to complete on removed device
When a SCSI device is removed while in active use, currently sg will
immediately return -ENODEV on any attempt to wait for active commands that
were sent before the removal. This is problematic for commands that use
SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel
when userspace frees or reuses it after getting ENODEV, leading to
corrupted userspace memory (in the case of READ-type commands) or corrupted
data being sent to the device (in the case of WRITE-type commands). This
has been seen in practice when logging out of a iscsi_tcp session, where
the iSCSI driver may still be processing commands after the device has been
marked for removal.
Change the policy to allow userspace to wait for active sg commands even
when the device is being removed. Return -ENODEV only when there are no
more responses to read.
CVE-2022-50215
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Fix linkwatch use-after-free on disconnect
usbnet uses the work usbnet_deferred_kevent() to perform tasks which may
sleep. On disconnect, completion of the work was originally awaited in
->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic
commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock":
https://git.kernel.org/tglx/history/c/0f138bbfd83c
The change was made because back then, the kernel's workqueue
implementation did not allow waiting for a single work. One had to wait
for completion of *all* work by calling flush_scheduled_work(), and that
could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex
held in ->ndo_stop().
The commit solved one problem but created another: It causes a
use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,
ax88179_178a.c, ch9200.c and smsc75xx.c:
* If the drivers receive a link change interrupt immediately before
disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)
->status() callback and schedule usbnet_deferred_kevent().
* usbnet_deferred_kevent() invokes the driver's ->link_reset() callback,
which calls netif_carrier_{on,off}().
* That in turn schedules the work linkwatch_event().
Because usbnet_deferred_kevent() is awaited after unregister_netdev(),
netif_carrier_{on,off}() may operate on an unregistered netdev and
linkwatch_event() may run after free_netdev(), causing a use-after-free.
In 2010, usbnet was changed to only wait for a single instance of
usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf
("drivers/net: don't use flush_scheduled_work()").
Unfortunately the commit neglected to move the wait back to
->ndo_stop(). Rectify that omission at long last.
CVE-2022-50220
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak
For some sev ioctl interfaces, input may be passed that is less than or
equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP
firmware returns. In this case, kmalloc will allocate memory that is the
size of the input rather than the size of the data. Since PSP firmware
doesn't fully overwrite the buffer, the sev ioctl interfaces with the
issue may return uninitialized slab memory.
Currently, all of the ioctl interfaces in the ccp driver are safe, but
to prevent future problems, change all ioctl interfaces that allocate
memory with kmalloc to use kzalloc and memset the data buffer to zero
in sev_ioctl_do_platform_status.
CVE-2022-50226
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0
Don't BUG/WARN on interrupt injection due to GIF being cleared,
since it's trivial for userspace to force the situation via
KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct
for KVM internally generated injections).
kernel BUG at arch/x86/kvm/svm/svm.c:3386!
invalid opcode: 0000 [#1] SMP
CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]
Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53
RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006
RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0
RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000
FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0
Call Trace:
<TASK>
inject_pending_event+0x2f7/0x4c0 [kvm]
kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm]
kvm_vcpu_ioctl+0x26d/0x650 [kvm]
__x64_sys_ioctl+0x82/0xb0
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
</TASK>
CVE-2022-50228
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: bcd2000: Fix a UAF bug on the error path of probing
When the driver fails in snd_card_register() at probe time, it will free
the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug.
The following log can reveal it:
[ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]
[ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0
[ 50.729530] Call Trace:
[ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]
Fix this by adding usb_kill_urb() before usb_free_urb().
CVE-2022-50229
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name}
Both dev_name and short_name are not guaranteed to be NULL terminated so
this instead use strnlen and then attempt to determine if the resulting
string needs to be truncated or not.
CVE-2022-50233
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Fix crash on isr after kexec()
If the system is rebooted via isr(), the IRQ handler might
be triggered before the domain is initialized. Resulting on
an invalid memory access error.
Fix:
[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070
[ 0.501166] Call trace:
[ 0.501174] report_iommu_fault+0x28/0xfc
[ 0.501180] mtk_iommu_isr+0x10c/0x1c0
[ joro: Fixed spelling in commit message ]
CVE-2022-50236
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()
If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp
needs to be freed.
CVE-2022-50242
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()
If device_register() fails in cxl_pci_afu|adapter(), the device
is not added, device_unregister() can not be called in the error
path, otherwise it will cause a null-ptr-deref because of removing
not added device.
As comment of device_register() says, it should use put_device() to give
up the reference in the error path. So split device_unregister() into
device_del() and put_device(), then goes to put dev when register fails.
CVE-2022-50244
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
memory: of: Fix refcount leak bug in of_get_ddr_timings()
We should add the of_node_put() when breaking out of
for_each_child_of_node() as it will automatically increase
and decrease the refcount.
CVE-2022-50249
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igb: Do not free q_vector unless new one was allocated
Avoid potential use-after-free condition under memory pressure. If the
kzalloc() fails, q_vector will be freed but left in the original
adapter->q_vector[v_idx] array position.
CVE-2022-50252
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
xen/gntdev: Prevent leaking grants
Prior to this commit, if a grant mapping operation failed partially,
some of the entries in the map_ops array would be invalid, whereas all
of the entries in the kmap_ops array would be valid. This in turn would
cause the following logic in gntdev_map_grant_pages to become invalid:
for (i = 0; i < map->count; i++) {
if (map->map_ops[i].status == GNTST_okay) {
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (!use_ptemod)
alloced++;
}
if (use_ptemod) {
if (map->kmap_ops[i].status == GNTST_okay) {
if (map->map_ops[i].status == GNTST_okay)
alloced++;
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
}
}
}
...
atomic_add(alloced, &map->live_grants);
Assume that use_ptemod is true (i.e., the domain mapping the granted
pages is a paravirtualized domain). In the code excerpt above, note that
the "alloced" variable is only incremented when both kmap_ops[i].status
and map_ops[i].status are set to GNTST_okay (i.e., both mapping
operations are successful). However, as also noted above, there are
cases where a grant mapping operation fails partially, breaking the
assumption of the code excerpt above.
The aforementioned causes map->live_grants to be incorrectly set. In
some cases, all of the map_ops mappings fail, but all of the kmap_ops
mappings succeed, meaning that live_grants may remain zero. This in turn
makes it impossible to unmap the successfully grant-mapped pages pointed
to by kmap_ops, because unmap_grant_pages has the following snippet of
code at its beginning:
if (atomic_read(&map->live_grants) == 0)
return; /* Nothing to do */
In other cases where only some of the map_ops mappings fail but all
kmap_ops mappings succeed, live_grants is made positive, but when the
user requests unmapping the grant-mapped pages, __unmap_grant_pages_done
will then make map->live_grants negative, because the latter function
does not check if all of the pages that were requested to be unmapped
were actually unmapped, and the same function unconditionally subtracts
"data->count" (i.e., a value that can be greater than map->live_grants)
from map->live_grants. The side effects of a negative live_grants value
have not been studied.
The net effect of all of this is that grant references are leaked in one
of the above conditions. In Qubes OS v4.1 (which uses Xen's grant
mechanism extensively for X11 GUI isolation), this issue manifests
itself with warning messages like the following to be printed out by the
Linux kernel in the VM that had granted pages (that contain X11 GUI
window data) to dom0: "g.e. 0x1234 still pending", especially after the
user rapidly resizes GUI VM windows (causing some grant-mapping
operations to partially or completely fail, due to the fact that the VM
unshares some of the pages as part of the window resizing, making the
pages impossible to grant-map from dom0).
The fix for this issue involves counting all successful map_ops and
kmap_ops mappings separately, and then adding the sum to live_grants.
During unmapping, only the number of successfully unmapped grants is
subtracted from live_grants. The code is also modified to check for
negative live_grants values after the subtraction and warn the user.
CVE-2022-50257
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()
This patch fixes a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware
version string by memcpy() in brcmf_fil_iovar_data_get().
The patch ensures buf is null-terminated.
Found by a modified version of syzkaller.
[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3
[ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 47.601565][ T1897] ==================================================================
[ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0
[ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897
[ 47.604336][ T1897]
[ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131
[ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event
[ 47.607453][ T1897] Call Trace:
[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1
[ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334
[ 47.609009][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609434][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609863][ T1897] kasan_report.cold+0x83/0xdf
[ 47.610366][ T1897] ? strsep+0x1b2/0x1f0
[ 47.610882][ T1897] strsep+0x1b2/0x1f0
[ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0
[ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40
[ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0
[ 47.614704][ T1897] ? find_held_lock+0x2d/0x110
[ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260
[ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 47.616288][ T1897] brcmf_attach+0x246/0xd40
[ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0
[ 47.617280][ T1897] ? kmemdup+0x43/0x50
[ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690
[ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760
[ 47.619429][ T1897] ? usb_probe_device+0x250/0x250
[ 47.619950][ T1897] really_probe+0x205/0xb70
[ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.622209][ T1897] driver_probe_device+0x4e/0x150
[ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0
[ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0
[ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30
[ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160
[ 47.625437][ T1897] __device_attach+0x23f/0x3a0
[ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0
[ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0
[ 47.627057][ T1897] bus_probe_device+0x1da/0x290
[ 47.627557][ T1897] device_add+0xb7b/0x1eb0
[ 47.628027][ T1897] ? wait_for_completion+0x290/0x290
[ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0
[ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0
[ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0
[ 47.630385][ T1897] usb_probe_device+0xbb/0x250
[ 47.630927][ T1897] ? usb_suspend+0x590/0x590
[ 47.631397][ T1897] really_probe+0x205/0xb70
[ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.633002][
---truncated---
CVE-2022-50258
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
kcm: annotate data-races around kcm->rx_wait
kcm->rx_psock can be read locklessly in kcm_rfree().
Annotate the read and writes accordingly.
syzbot reported:
BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree
write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:
reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]
kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363
__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301
strp_recv+0x6d/0x80 net/strparser/strparser.c:335
tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703
strp_read_sock net/strparser/strparser.c:358 [inline]
do_strp_work net/strparser/strparser.c:406 [inline]
strp_work+0xe8/0x180 net/strparser/strparser.c:415
process_one_work+0x3d3/0x720 kernel/workqueue.c:2289
worker_thread+0x618/0xa70 kernel/workqueue.c:2436
kthread+0x1a9/0x1e0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:
kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181
skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841
skb_release_all net/core/skbuff.c:852 [inline]
__kfree_skb net/core/skbuff.c:868 [inline]
kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891
kfree_skb include/linux/skbuff.h:1216 [inline]
kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161
____sys_recvmsg+0x16c/0x2e0
___sys_recvmsg net/socket.c:2743 [inline]
do_recvmmsg+0x2f1/0x710 net/socket.c:2837
__sys_recvmmsg net/socket.c:2916 [inline]
__do_sys_recvmmsg net/socket.c:2939 [inline]
__se_sys_recvmmsg net/socket.c:2932 [inline]
__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x01 -> 0x00
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
CVE-2022-50265
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix check for probe enabled in kill_kprobe()
In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be
called always fails. This is because before that we set the
KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always
false.
The disarm_kprobe_ftrace() call introduced by commit:
0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")
to fix the NULL pointer reference problem. When the probe is enabled, if
we do not disarm it, this problem still exists.
Fix it by putting the probe enabled check before setting the
KPROBE_FLAG_GONE flag.
CVE-2022-50266
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vhost/vsock: Use kvmalloc/kvfree for larger packets.
When copying a large file over sftp over vsock, data size is usually 32kB,
and kmalloc seems to fail to try to allocate 32 32kB regions.
vhost-5837: page allocation failure: order:4, mode:0x24040c0
Call Trace:
[<ffffffffb6a0df64>] dump_stack+0x97/0xdb
[<ffffffffb68d6aed>] warn_alloc_failed+0x10f/0x138
[<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8
[<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d
[<ffffffffb6646e56>] alloc_kmem_pages+0x17/0x19
[<ffffffffb6653a26>] kmalloc_order_trace+0x2b/0xdb
[<ffffffffb66682f3>] __kmalloc+0x177/0x1f7
[<ffffffffb66e0d94>] ? copy_from_iter+0x8d/0x31d
[<ffffffffc0689ab7>] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock]
[<ffffffffc06828d9>] vhost_worker+0xf7/0x157 [vhost]
[<ffffffffb683ddce>] kthread+0xfd/0x105
[<ffffffffc06827e2>] ? vhost_dev_set_owner+0x22e/0x22e [vhost]
[<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3
[<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80
[<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3
Work around by doing kvmalloc instead.
CVE-2022-50271
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PNP: fix name memory leak in pnp_alloc_dev()
After commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
move dev_set_name() after pnp_add_id() to avoid memory leak.
CVE-2022-50278
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pnode: terminate at peers of source
The propagate_mnt() function handles mount propagation when creating
mounts and propagates the source mount tree @source_mnt to all
applicable nodes of the destination propagation mount tree headed by
@dest_mnt.
Unfortunately it contains a bug where it fails to terminate at peers of
@source_mnt when looking up copies of the source mount that become
masters for copies of the source mount tree mounted on top of slaves in
the destination propagation tree causing a NULL dereference.
Once the mechanics of the bug are understood it's easy to trigger.
Because of unprivileged user namespaces it is available to unprivileged
users.
While fixing this bug we've gotten confused multiple times due to
unclear terminology or missing concepts. So let's start this with some
clarifications:
* The terms "master" or "peer" denote a shared mount. A shared mount
belongs to a peer group.
* A peer group is a set of shared mounts that propagate to each other.
They are identified by a peer group id. The peer group id is available
in @shared_mnt->mnt_group_id.
Shared mounts within the same peer group have the same peer group id.
The peers in a peer group can be reached via @shared_mnt->mnt_share.
* The terms "slave mount" or "dependent mount" denote a mount that
receives propagation from a peer in a peer group. IOW, shared mounts
may have slave mounts and slave mounts have shared mounts as their
master. Slave mounts of a given peer in a peer group are listed on
that peers slave list available at @shared_mnt->mnt_slave_list.
* The term "master mount" denotes a mount in a peer group. IOW, it
denotes a shared mount or a peer mount in a peer group. The term
"master mount" - or "master" for short - is mostly used when talking
in the context of slave mounts that receive propagation from a master
mount. A master mount of a slave identifies the closest peer group a
slave mount receives propagation from. The master mount of a slave can
be identified via @slave_mount->mnt_master. Different slaves may point
to different masters in the same peer group.
* Multiple peers in a peer group can have non-empty ->mnt_slave_lists.
Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to
ensure all slave mounts of a peer group are visited the
->mnt_slave_lists of all peers in a peer group have to be walked.
* Slave mounts point to a peer in the closest peer group they receive
propagation from via @slave_mnt->mnt_master (see above). Together with
these peers they form a propagation group (see below). The closest
peer group can thus be identified through the peer group id
@slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave
mount receives propagation from.
* A shared-slave mount is a slave mount to a peer group pg1 while also
a peer in another peer group pg2. IOW, a peer group may receive
propagation from another peer group.
If a peer group pg1 is a slave to another peer group pg2 then all
peers in peer group pg1 point to the same peer in peer group pg2 via
->mnt_master. IOW, all peers in peer group pg1 appear on the same
->mnt_slave_list. IOW, they cannot be slaves to different peer groups.
* A pure slave mount is a slave mount that is a slave to a peer group
but is not a peer in another peer group.
* A propagation group denotes the set of mounts consisting of a single
peer group pg1 and all slave mounts and shared-slave mounts that point
to a peer in that peer group via ->mnt_master. IOW, all slave mounts
such that @slave_mnt->mnt_master->mnt_group_id is equal to
@shared_mnt->mnt_group_id.
The concept of a propagation group makes it easier to talk about a
single propagation level in a propagation tree.
For example, in propagate_mnt() the immediate peers of @dest_mnt and
all slaves of @dest_mnt's peer group form a propagation group pr
---truncated---
CVE-2022-50280
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
chardev: fix error handling in cdev_device_add()
While doing fault injection test, I got the following report:
------------[ cut here ]------------
kobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called.
WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0
CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:kobject_put+0x23d/0x4e0
Call Trace:
<TASK>
cdev_device_add+0x15e/0x1b0
__iio_device_register+0x13b4/0x1af0 [industrialio]
__devm_iio_device_register+0x22/0x90 [industrialio]
max517_probe+0x3d8/0x6b4 [max517]
i2c_device_probe+0xa81/0xc00
When device_add() is injected fault and returns error, if dev->devt is not set,
cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev->devt
in error path.
CVE-2022-50282
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages
The h->*_huge_pages counters are protected by the hugetlb_lock, but
alloc_huge_page has a corner case where it can decrement the counter
outside of the lock.
This could lead to a corrupted value of h->resv_huge_pages, which we have
observed on our systems.
Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a
potential race.
CVE-2022-50285
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure
adapter->dcb would get silently freed inside qlcnic_dcb_enable() in
case qlcnic_dcb_attach() would return an error, which always happens
under OOM conditions. This would lead to use-after-free because both
of the existing callers invoke qlcnic_dcb_get_info() on the obtained
pointer, which is potentially freed at that point.
Propagate errors from qlcnic_dcb_enable(), and instead free the dcb
pointer at callsite using qlcnic_dcb_free(). This also removes the now
unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around
kfree() also causing memory leaks for partially initialized dcb.
Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.
CVE-2022-50288
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix memory leak in ocfs2_stack_glue_init()
ocfs2_table_header should be free in ocfs2_stack_glue_init() if
ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak.
BUG: memory leak
unreferenced object 0xffff88810eeb5800 (size 128):
comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s)
hex dump (first 32 bytes):
c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@..............
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0
[<00000000c04f70f7>] 0xffffffffa0050037
[<000000001bd12912>] do_one_initcall+0xdb/0x480
[<0000000064f766c9>] do_init_module+0x1cf/0x680
[<000000002ba52db0>] load_module+0x6441/0x6f20
[<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0
[<00000000380c1f22>] do_syscall_64+0x3f/0x90
[<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVE-2022-50289
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kcm: annotate data-races around kcm->rx_psock
kcm->rx_psock can be read locklessly in kcm_rfree().
Annotate the read and writes accordingly.
We do the same for kcm->rx_wait in the following patch.
syzbot reported:
BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm
write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:
unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313
kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373
__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301
strp_recv+0x6d/0x80 net/strparser/strparser.c:335
tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703
strp_read_sock net/strparser/strparser.c:358 [inline]
do_strp_work net/strparser/strparser.c:406 [inline]
strp_work+0xe8/0x180 net/strparser/strparser.c:415
process_one_work+0x3d3/0x720 kernel/workqueue.c:2289
worker_thread+0x618/0xa70 kernel/workqueue.c:2436
kthread+0x1a9/0x1e0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:
kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181
skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841
skb_release_all net/core/skbuff.c:852 [inline]
__kfree_skb net/core/skbuff.c:868 [inline]
kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891
kfree_skb include/linux/skbuff.h:1216 [inline]
kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161
____sys_recvmsg+0x16c/0x2e0
___sys_recvmsg net/socket.c:2743 [inline]
do_recvmmsg+0x2f1/0x710 net/socket.c:2837
__sys_recvmmsg net/socket.c:2916 [inline]
__do_sys_recvmmsg net/socket.c:2939 [inline]
__se_sys_recvmmsg net/socket.c:2932 [inline]
__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0xffff88812971ce00 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
CVE-2022-50291
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a range
If we get -ENOMEM while dropping file extent items in a given range, at
btrfs_drop_extents(), due to failure to allocate memory when attempting to
increment the reference count for an extent or drop the reference count,
we handle it with a BUG_ON(). This is excessive, instead we can simply
abort the transaction and return the error to the caller. In fact most
callers of btrfs_drop_extents(), directly or indirectly, already abort
the transaction if btrfs_drop_extents() returns any error.
Also, we already have error paths at btrfs_drop_extents() that may return
-ENOMEM and in those cases we abort the transaction, like for example
anything that changes the b+tree may return -ENOMEM due to a failure to
allocate a new extent buffer when COWing an existing extent buffer, such
as a call to btrfs_duplicate_item() for example.
So replace the BUG_ON() calls with proper logic to abort the transaction
and return the error.
CVE-2022-50293
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix memory leak in lbs_init_adapter()
When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not
released. Add free memory to processing error path.
CVE-2022-50294
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: verify the expected usb_endpoints are present
The bug arises when a USB device claims to be an ATH9K but doesn't
have the expected endpoints. (In this case there was an interrupt
endpoint where the driver expected a bulk endpoint.) The kernel
needs to be able to handle such devices without getting an internal error.
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493
Modules linked in:
CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Workqueue: events request_firmware_work_func
RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493
Call Trace:
ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline]
ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019
ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline]
ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242
request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097
process_one_work+0x9af/0x1600 kernel/workqueue.c:2279
worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425
kthread+0x3b4/0x4a0 kernel/kthread.c:313
ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2022-50297
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md: Replace snprintf with scnprintf
Current code produces a warning as shown below when total characters
in the constituent block device names plus the slashes exceeds 200.
snprintf() returns the number of characters generated from the given
input, which could cause the expression “200 - len” to wrap around
to a large positive number. Fix this by using scnprintf() instead,
which returns the actual number of characters written into the buffer.
[ 1513.267938] ------------[ cut here ]------------
[ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510
[ 1513.267944] Modules linked in: <snip>
[ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu
[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510
<-snip->
[ 1513.267982] Call Trace:
[ 1513.267986] snprintf+0x45/0x70
[ 1513.267990] ? disk_name+0x71/0xa0
[ 1513.267993] dump_zones+0x114/0x240 [raid0]
[ 1513.267996] ? _cond_resched+0x19/0x40
[ 1513.267998] raid0_run+0x19e/0x270 [raid0]
[ 1513.268000] md_run+0x5e0/0xc50
[ 1513.268003] ? security_capable+0x3f/0x60
[ 1513.268005] do_md_run+0x19/0x110
[ 1513.268006] md_ioctl+0x195e/0x1f90
[ 1513.268007] blkdev_ioctl+0x91f/0x9f0
[ 1513.268010] block_ioctl+0x3d/0x50
[ 1513.268012] do_vfs_ioctl+0xa9/0x640
[ 1513.268014] ? __fput+0x162/0x260
[ 1513.268016] ksys_ioctl+0x75/0x80
[ 1513.268017] __x64_sys_ioctl+0x1a/0x20
[ 1513.268019] do_syscall_64+0x5e/0x200
[ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9
CVE-2022-50299
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mtd: core: fix possible resource leak in init_mtd()
I got the error report while inject fault in init_mtd():
sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'
Call Trace:
<TASK>
dump_stack_lvl+0x67/0x83
sysfs_warn_dup+0x60/0x70
sysfs_create_dir_ns+0x109/0x120
kobject_add_internal+0xce/0x2f0
kobject_add+0x98/0x110
device_add+0x179/0xc00
device_create_groups_vargs+0xf4/0x100
device_create+0x7b/0xb0
bdi_register_va.part.13+0x58/0x2d0
bdi_register+0x9b/0xb0
init_mtd+0x62/0x171 [mtd]
do_one_initcall+0x6c/0x3c0
do_init_module+0x58/0x222
load_module+0x268e/0x27d0
__do_sys_finit_module+0xd5/0x140
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
kobject_add_internal failed for mtd-0 with -EEXIST, don't try to register
things with the same name in the same directory.
Error registering mtd class or bdi: -17
If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,
as a result, we can't load the mtd module again, to fix this by calling
bdi_unregister(mtd_bdi) after out_procfs label.
CVE-2022-50304
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cxl: Fix refcount leak in cxl_calc_capp_routing
of_get_next_parent() returns a node pointer with refcount incremented,
we should use of_node_put() on it when not need anymore.
This function only calls of_node_put() in normal path,
missing it in the error path.
Add missing of_node_put() to avoid refcount leak.
CVE-2022-50311
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers: serial: jsm: fix some leaks in probe
This error path needs to unwind instead of just returning directly.
CVE-2022-50312
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()
The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb
in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it.
Compile tested only.
CVE-2022-50321
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value
The return value of acpi_fetch_acpi_dev() could be NULL, which would
cause a NULL pointer dereference to occur in acpi_device_hid().
[ rjw: Subject and changelog edits, added empty line after if () ]
CVE-2022-50327
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
crypto: cavium - prevent integer overflow loading firmware
The "code_length" value comes from the firmware file. If your firmware
is untrusted realistically there is probably very little you can do to
protect yourself. Still we try to limit the damage as much as possible.
Also Smatch marks any data read from the filesystem as untrusted and
prints warnings if it not capped correctly.
The "ntohl(ucode->code_length) * 2" multiplication can have an
integer overflow.
CVE-2022-50330
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix null-ptr-deref in ext4_write_info
I caught a null-ptr-deref bug as follows:
==================================================================
KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339
RIP: 0010:ext4_write_info+0x53/0x1b0
[...]
Call Trace:
dquot_writeback_dquots+0x341/0x9a0
ext4_sync_fs+0x19e/0x800
__sync_filesystem+0x83/0x100
sync_filesystem+0x89/0xf0
generic_shutdown_super+0x79/0x3e0
kill_block_super+0xa1/0x110
deactivate_locked_super+0xac/0x130
deactivate_super+0xb6/0xd0
cleanup_mnt+0x289/0x400
__cleanup_mnt+0x16/0x20
task_work_run+0x11c/0x1c0
exit_to_user_mode_prepare+0x203/0x210
syscall_exit_to_user_mode+0x5b/0x3a0
do_syscall_64+0x59/0x70
entry_SYSCALL_64_after_hwframe+0x44/0xa9
==================================================================
Above issue may happen as follows:
-------------------------------------
exit_to_user_mode_prepare
task_work_run
__cleanup_mnt
cleanup_mnt
deactivate_super
deactivate_locked_super
kill_block_super
generic_shutdown_super
shrink_dcache_for_umount
dentry = sb->s_root
sb->s_root = NULL <--- Here set NULL
sync_filesystem
__sync_filesystem
sb->s_op->sync_fs > ext4_sync_fs
dquot_writeback_dquots
sb->dq_op->write_info > ext4_write_info
ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2)
d_inode(sb->s_root)
s_root->d_inode <--- Null pointer dereference
To solve this problem, we use ext4_journal_start_sb directly
to avoid s_root being used.
CVE-2022-50344
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: init quota for 'old.inode' in 'ext4_rename'
Syzbot found the following issue:
ext4_parse_param: s_want_extra_isize=128
ext4_inode_info_init: s_want_extra_isize=32
ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828
__ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128
__ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128
ext4_xattr_block_set: inode=ffff88823869a2c8
------------[ cut here ]------------
WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980
Modules linked in:
RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980
RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000
RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178
RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e
R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000
R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000
FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? ext4_xattr_set_entry+0x3b7/0x2320
? ext4_xattr_block_set+0x0/0x2020
? ext4_xattr_set_entry+0x0/0x2320
? ext4_xattr_check_entries+0x77/0x310
? ext4_xattr_ibody_set+0x23b/0x340
ext4_xattr_move_to_block+0x594/0x720
ext4_expand_extra_isize_ea+0x59a/0x10f0
__ext4_expand_extra_isize+0x278/0x3f0
__ext4_mark_inode_dirty.cold+0x347/0x410
ext4_rename+0xed3/0x174f
vfs_rename+0x13a7/0x2510
do_renameat2+0x55d/0x920
__x64_sys_rename+0x7d/0xb0
do_syscall_64+0x3b/0xa0
entry_SYSCALL_64_after_hwframe+0x72/0xdc
As 'ext4_rename' will modify 'old.inode' ctime and mark inode dirty,
which may trigger expand 'extra_isize' and allocate block. If inode
didn't init quota will lead to warning. To solve above issue, init
'old.inode' firstly in 'ext4_rename'.
CVE-2022-50346
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()
If device_register() returns error in tifm_7xx1_switch_media(),
name of kobject which is allocated in dev_set_name() called in device_add()
is leaked.
Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized.
CVE-2022-50349
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix a race condition between login_work and the login thread
In case a malicious initiator sends some random data immediately after a
login PDU; the iscsi_target_sk_data_ready() callback will schedule the
login_work and, at the same time, the negotiation may end without clearing
the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are
required to complete the login).
The login has been completed but the login_work function will find the
LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling
itself; at this point, if the initiator drops the connection, the
iscsit_conn structure will be freed, login_work will dereference a released
socket structure and the kernel crashes.
BUG: kernel NULL pointer dereference, address: 0000000000000230
PF: supervisor write access in kernel mode
PF: error_code(0x0002) - not-present page
Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
RIP: 0010:_raw_read_lock_bh+0x15/0x30
Call trace:
iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]
process_one_work+0x1e8/0x3c0
Fix this bug by forcing login_work to stop after the login has been
completed and the socket callbacks have been restored.
Add a comment to clearify the return values of iscsi_target_do_login()
CVE-2022-50350
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix xid leak in cifs_create()
If the cifs already shutdown, we should free the xid before return,
otherwise, the xid will be leaked.
CVE-2022-50351
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: hns: fix possible memory leak in hnae_ae_register()
Inject fault while probing module, if device_register() fails,
but the refcount of kobject is not decreased to 0, the name
allocated in dev_set_name() is leaked. Fix this by calling
put_device(), so that name can be freed in callback function
kobject_cleanup().
unreferenced object 0xffff00c01aba2100 (size 128):
comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)
hex dump (first 32 bytes):
68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0
[<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0
[<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390
[<000000006c0ffb13>] kvasprintf+0x8c/0x118
[<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8
[<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0
[<000000000b87affc>] dev_set_name+0x7c/0xa0
[<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae]
[<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]
[<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
CVE-2022-50352
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfb_init() fails
When the default qdisc is sfb, if the qdisc of dev_queue fails to be
inited during mqprio_init(), sfb_reset() is invoked to clear resources.
In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
sfb_init()
tcf_block_get() --->failed, q->qdisc is NULL
...
qdisc_put()
...
sfb_reset()
qdisc_reset(q->qdisc) --->q->qdisc is NULL
ops = qdisc->ops
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:qdisc_reset+0x2b/0x6f0
Call Trace:
<TASK>
sfb_reset+0x37/0xd0
qdisc_reset+0xed/0x6f0
qdisc_destroy+0x82/0x4c0
qdisc_put+0x9e/0xb0
qdisc_create_dflt+0x2c3/0x4a0
mqprio_init+0xa71/0x1760
qdisc_create+0x3eb/0x1000
tc_modify_qdisc+0x408/0x1720
rtnetlink_rcv_msg+0x38e/0xac0
netlink_rcv_skb+0x12d/0x3a0
netlink_unicast+0x4a2/0x740
netlink_sendmsg+0x826/0xcc0
sock_sendmsg+0xc5/0x100
____sys_sendmsg+0x583/0x690
___sys_sendmsg+0xe8/0x160
__sys_sendmsg+0xbf/0x160
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f2164122d04
</TASK>
CVE-2022-50356
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: cx88: Fix a null-ptr-deref bug in buffer_prepare()
When the driver calls cx88_risc_buffer() to prepare the buffer, the
function call may fail, resulting in a empty buffer and null-ptr-deref
later in buffer_queue().
The following log can reveal it:
[ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
[ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500
[ 41.836311] Call Trace:
[ 41.836945] __enqueue_in_driver+0x141/0x360
[ 41.837262] vb2_start_streaming+0x62/0x4a0
[ 41.838216] vb2_core_streamon+0x1da/0x2c0
[ 41.838516] __vb2_init_fileio+0x981/0xbc0
[ 41.839141] __vb2_perform_fileio+0xbf9/0x1120
[ 41.840072] vb2_fop_read+0x20e/0x400
[ 41.840346] v4l2_read+0x215/0x290
[ 41.840603] vfs_read+0x162/0x4c0
Fix this by checking the return value of cx88_risc_buffer()
[hverkuil: fix coding style issues]
CVE-2022-50359
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: mux: reg: check return value after calling platform_get_resource()
It will cause null-ptr-deref in resource_size(), if platform_get_resource()
returns NULL, move calling resource_size() after devm_ioremap_resource() that
will check 'res' to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.
CVE-2022-50364
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
skbuff: Account for tail adjustment during pull operations
Extending the tail can have some unexpected side effects if a program uses
a helper like BPF_FUNC_skb_pull_data to read partial content beyond the
head skb headlen when all the skbs in the gso frag_list are linear with no
head_frag -
kernel BUG at net/core/skbuff.c:4219!
pc : skb_segment+0xcf4/0xd2c
lr : skb_segment+0x63c/0xd2c
Call trace:
skb_segment+0xcf4/0xd2c
__udp_gso_segment+0xa4/0x544
udp4_ufo_fragment+0x184/0x1c0
inet_gso_segment+0x16c/0x3a4
skb_mac_gso_segment+0xd4/0x1b0
__skb_gso_segment+0xcc/0x12c
udp_rcv_segment+0x54/0x16c
udp_queue_rcv_skb+0x78/0x144
udp_unicast_rcv_skb+0x8c/0xa4
__udp4_lib_rcv+0x490/0x68c
udp_rcv+0x20/0x30
ip_protocol_deliver_rcu+0x1b0/0x33c
ip_local_deliver+0xd8/0x1f0
ip_rcv+0x98/0x1a4
deliver_ptype_list_skb+0x98/0x1ec
__netif_receive_skb_core+0x978/0xc60
Fix this by marking these skbs as GSO_DODGY so segmentation can handle
the tail updates accordingly.
CVE-2022-50365
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: fix UAF/GPF bug in nilfs_mdt_destroy
In alloc_inode, inode_init_always() could return -ENOMEM if
security_inode_alloc() fails, which causes inode->i_private
uninitialized. Then nilfs_is_metadata_file_inode() returns
true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),
which frees the uninitialized inode->i_private
and leads to crashes(e.g., UAF/GPF).
Fix this by moving security_inode_alloc just prior to
this_cpu_inc(nr_inodes)
CVE-2022-50367
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502668/
CVE-2022-50368
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix memory leak when build ntlmssp negotiate blob failed
There is a memory leak when mount cifs:
unreferenced object 0xffff888166059600 (size 448):
comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s)
hex dump (first 32 bytes):
fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000060609a61>] mempool_alloc+0xe1/0x260
[<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60
[<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460
[<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0
[<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480
[<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410
[<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0
[<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0
[<000000006cbc43d9>] mount_get_conns+0x7a/0x730
[<000000005922d816>] cifs_mount+0x103/0xd10
[<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90
[<0000000078034979>] smb3_get_tree+0x1d5/0x300
[<000000004371f980>] vfs_get_tree+0x41/0xf0
[<00000000b670d8a7>] path_mount+0x9b3/0xdd0
[<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0
[<000000009404c3b9>] do_syscall_64+0x35/0x80
When build ntlmssp negotiate blob failed, the session setup request
should be freed.
CVE-2022-50372
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown
lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can
still occur which in turn tries to access dma apis if lpuart_dma_tx_use
flag is true. At this point since dma is torn down, these dma apis can
abort. Set lpuart_dma_tx_use and the corresponding rx flag
lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not
accessed after they are relinquished.
Otherwise, when try to kill btattach, kernel may panic. This patch may
fix this issue.
root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200
^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
[ 90.189806] Modules linked in: moal(O) mlan(O)
[ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37
[ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT)
[ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60
[ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c
[ 90.225237] sp : ffff800013f0bac0
[ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800
[ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00
[ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000
[ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000
[ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040
[ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090
[ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804
[ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480
[ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800
[ 90.299876] Call trace:
[ 90.302321] fsl_edma3_disable_request+0x8/0x60
[ 90.306851] lpuart_flush_buffer+0x40/0x160
[ 90.311037] uart_flush_buffer+0x88/0x120
[ 90.315050] tty_driver_flush_buffer+0x20/0x30
[ 90.319496] hci_uart_flush+0x44/0x90
[ 90.323162] +0x34/0x12c
[ 90.327253] tty_ldisc_close+0x38/0x70
[ 90.331005] tty_ldisc_release+0xa8/0x190
[ 90.335018] tty_release_struct+0x24/0x8c
[ 90.339022] tty_release+0x3ec/0x4c0
[ 90.342593] __fput+0x70/0x234
[ 90.345652] ____fput+0x14/0x20
[ 90.348790] task_work_run+0x84/0x17c
[ 90.352455] do_exit+0x310/0x96c
[ 90.355688] do_group_exit+0x3c/0xa0
[ 90.359259] __arm64_sys_exit_group+0x1c/0x20
[ 90.363609] invoke_syscall+0x48/0x114
[ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc
[ 90.372068] do_el0_svc+0x2c/0x94
[ 90.375379] el0_svc+0x28/0x80
[ 90.378438] el0t_64_sync_handler+0xa8/0x130
[ 90.382711] el0t_64_sync+0x1a0/0x1a4
[ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041)
[ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]---
[ 90.397073] note: btattach[503] exited with preempt_count 1
[ 90.402636] Fixing recursive fault but reboot is needed!
CVE-2022-50375
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md: fix a crash in mempool_free
There's a crash in mempool_free when running the lvm test
shell/lvchange-rebuild-raid.sh.
The reason for the crash is this:
* super_written calls atomic_dec_and_test(&mddev->pending_writes) and
wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev)
and bio_put(bio).
* so, the process that waited on sb_wait and that is woken up is racing
with bio_put(bio).
* if the process wins the race, it calls bioset_exit before bio_put(bio)
is executed.
* bio_put(bio) attempts to free a bio into a destroyed bio set - causing
a crash in mempool_free.
We fix this bug by moving bio_put before atomic_dec_and_test.
We also move rdev_dec_pending before atomic_dec_and_test as suggested by
Neil Brown.
The function md_end_flush has a similar bug - we must call bio_put before
we decrement the number of in-progress bios.
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 11557f0067 P4D 11557f0067 PUD 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Workqueue: kdelayd flush_expired_bios [dm_delay]
RIP: 0010:mempool_free+0x47/0x80
Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00
RSP: 0018:ffff88910036bda8 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8
RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900
R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000
R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05
FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0
Call Trace:
<TASK>
clone_endio+0xf4/0x1c0 [dm_mod]
clone_endio+0xf4/0x1c0 [dm_mod]
__submit_bio+0x76/0x120
submit_bio_noacct_nocheck+0xb6/0x2a0
flush_expired_bios+0x28/0x2f [dm_delay]
process_one_work+0x1b4/0x300
worker_thread+0x45/0x3e0
? rescuer_thread+0x380/0x380
kthread+0xc2/0x100
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
</TASK>
Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [last unloaded: brd]
CR2: 0000000000000000
---[ end trace 0000000000000000 ]---
CVE-2022-50381
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix an Oops in nfs_d_automount()
When mounting from a NFSv4 referral, path->dentry can end up being a
negative dentry, so derive the struct nfs_server from the dentry
itself instead.
CVE-2022-50385
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix user-after-free
This uses l2cap_chan_hold_unless_zero() after calling
__l2cap_get_chan_blah() to prevent the following trace:
Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref
*kref)
Bluetooth: chan 0000000023c4974d
Bluetooth: parent 00000000ae861c08
==================================================================
BUG: KASAN: use-after-free in __mutex_waiter_is_first
kernel/locking/mutex.c:191 [inline]
BUG: KASAN: use-after-free in __mutex_lock_common
kernel/locking/mutex.c:671 [inline]
BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400
kernel/locking/mutex.c:729
Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
CVE-2022-50386
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak
In crb_acpi_add(), we get the TPM2 table to retrieve information
like start method, and then assign them to the priv data, so the
TPM2 table is not used after the init, should be freed, call
acpi_put_table() to fix the memory leak.
CVE-2022-50389
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: ismt: Fix an out-of-bounds bug in ismt_access()
When the driver does not check the data from the user, the variable
'data->block[0]' may be very large to cause an out-of-bounds bug.
The following log can reveal it:
[ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20
[ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE
[ 33.996475] ==================================================================
[ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b
[ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485
[ 33.999450] Call Trace:
[ 34.001849] memcpy+0x20/0x60
[ 34.002077] ismt_access.cold+0x374/0x214b
[ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0
[ 34.004007] i2c_smbus_xfer+0x10a/0x390
[ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710
[ 34.005196] i2cdev_ioctl+0x5ec/0x74c
Fix this bug by checking the size of 'data->block[0]' first.
CVE-2022-50394
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
integrity: Fix memory leakage in keyring allocation error path
Key restriction is allocated in integrity_init_keyring(). However, if
keyring allocation failed, it is not freed, causing memory leaks.
CVE-2022-50395
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_set_parms
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810c287f00 (size 256):
comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline]
[<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline]
[<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline]
[<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342
[<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553
[<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147
[<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082
[<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540
[<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
[<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345
[<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921
[<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline]
[<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734
[<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482
[<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536
[<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622
[<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline]
[<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline]
[<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648
[<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
====================================
Kernel uses tcindex_change() to change an existing
filter properties.
Yet the problem is that, during the process of changing,
if `old_r` is retrieved from `p->perfect`, then
kernel uses tcindex_alloc_perfect_hash() to newly
allocate filter results, uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure, which triggers the above memory leak.
To be more specific, there are only two source for the `old_r`,
according to the tcindex_lookup(). `old_r` is retrieved from
`p->perfect`, or `old_r` is retrieved from `p->h`.
* If `old_r` is retrieved from `p->perfect`, kernel uses
tcindex_alloc_perfect_hash() to newly allocate the
filter results. Then `r` is assigned with `cp->perfect + handle`,
which is newly allocated. So condition `old_r && old_r != r` is
true in this situation, and kernel uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure
* If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL
according to the tcindex_lookup(). Considering that `cp->h`
is directly copied from `p->h` and `p->perfect` is NULL,
`r` is assigned with `tcindex_lookup(cp, handle)`, whose value
should be the same as `old_r`, so condition `old_r && old_r != r`
is false in this situation, kernel ignores using
tcindex_filter_result_init() to clear the old filter result.
So only when `old_r` is retrieved from `p->perfect` does kernel use
tcindex_filter_result_init() to clear the old filter result, which
triggers the above memory leak.
Considering that there already exists a tc_filter_wq workqueue
to destroy the old tcindex_d
---truncated---
CVE-2022-50396
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure
On error situation `clp->cl_cb_conn.cb_xprt` should not be given
a reference to the xprt otherwise both client cleanup and the
error handling path of the caller call to put it. Better to
delay handing over the reference to a later branch.
[ 72.530665] refcount_t: underflow; use-after-free.
[ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120
[ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc]
[ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1
[ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014
[ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd]
[ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120
[ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48
[ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286
[ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000
[ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0
[ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff
[ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180
[ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0
[ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000
[ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0
[ 72.554874] Call Trace:
[ 72.555278] <TASK>
[ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc]
[ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd]
[ 72.557087] ? update_load_avg+0x82/0x610
[ 72.557652] ? cpuacct_charge+0x60/0x70
[ 72.558212] ? dequeue_entity+0xdb/0x3e0
[ 72.558765] ? queued_spin_unlock+0x9/0x20
[ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd]
[ 72.560031] process_one_work+0x1df/0x390
[ 72.560600] worker_thread+0x37/0x3b0
[ 72.561644] ? process_one_work+0x390/0x390
[ 72.562247] kthread+0x12f/0x150
[ 72.562710] ? set_kthread_struct+0x50/0x50
[ 72.563309] ret_from_fork+0x22/0x30
[ 72.563818] </TASK>
[ 72.564189] ---[ end trace 031117b1c72ec616 ]---
[ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018).
[ 72.567647] ------------[ cut here ]------------
CVE-2022-50401
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drivers/md/md-bitmap: check the return value of md_bitmap_get_counter()
Check the return value of md_bitmap_get_counter() in case it returns
NULL pointer, which will result in a null pointer dereference.
v2: update the check to include other dereference
CVE-2022-50402
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/tunnel: wait until all sk_user_data reader finish before releasing the sock
There is a race condition in vxlan that when deleting a vxlan device
during receiving packets, there is a possibility that the sock is
released after getting vxlan_sock vs from sk_user_data. Then in
later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got
NULL pointer dereference. e.g.
#0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757
#1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d
#2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48
#3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b
#4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb
#5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542
#6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62
[exception RIP: vxlan_ecn_decapsulate+0x3b]
RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246
RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000
RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700
RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae
R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700
R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]
#8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507
#9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45
#10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807
#11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951
#12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde
#13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b
#14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139
#15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a
#16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3
#17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca
#18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3
Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh
Fix this by waiting for all sk_user_data reader to finish before
releasing the sock.
CVE-2022-50405
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iomap: iomap: fix memory corruption when recording errors during writeback
Every now and then I see this crash on arm64:
Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8
Buffer I/O error on dev dm-0, logical block 8733687, async page read
Mem abort info:
ESR = 0x0000000096000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x06: level 2 translation fault
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000
[00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
Buffer I/O error on dev dm-0, logical block 8733688, async page read
Dumping ftrace buffer:
Buffer I/O error on dev dm-0, logical block 8733689, async page read
(ftrace buffer empty)
XFS (dm-0): log I/O error -5
Modules linked in: dm_thin_pool dm_persistent_data
XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296).
dm_bio_prison
XFS (dm-0): Please unmount the filesystem and rectify the problem(s)
XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0
dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT
potentially unexpected fatal signal 6.
nf_reject_ipv6
potentially unexpected fatal signal 6.
ipt_REJECT nf_reject_ipv4
CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7
rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables
Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021
pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)
ip_tables
pc : 000003fd6d7df200
x_tables
lr : 000003fd6d7df1ec
overlay nfsv4
CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405
Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021
Workqueue: writeback wb_workfn
sp : 000003ffd9522fd0
(flush-253:0)
pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--)
pc : errseq_set+0x1c/0x100
x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780
x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000
x23: 00000000ffffffff x22: 0000000000000005
lr : __filemap_set_wb_err+0x24/0xe0
x21: 0000000000000006
sp : fffffe000f80f760
x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8
x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868
x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000
x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000
x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288
x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000
x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8
x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001
x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668
x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8
Call trace:
errseq_set+0x1c/0x100
__filemap_set_wb_err+0x24/0xe0
iomap_do_writepage+0x5e4/0xd5c
write_cache_pages+0x208/0x674
iomap_writepages+0x34/0x60
xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b]
x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180
x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288
x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee
x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020
x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000
CPU:
---truncated---
CVE-2022-50406
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()
> ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);
may be schedule, and then complete before the line
> ndev->stats.tx_bytes += skb->len;
[ 46.912801] ==================================================================
[ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]
[ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328
[ 46.935991]
[ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1
[ 46.947255] Hardware name: [REDACTED]
[ 46.954568] Call trace:
[ 46.957037] dump_backtrace+0x0/0x2b8
[ 46.960719] show_stack+0x24/0x30
[ 46.964052] dump_stack+0x128/0x194
[ 46.967557] print_address_description.isra.0+0x64/0x380
[ 46.972877] __kasan_report+0x1d4/0x240
[ 46.976723] kasan_report+0xc/0x18
[ 46.980138] __asan_report_load4_noabort+0x18/0x20
[ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]
[ 46.990613] dev_hard_start_xmit+0x1bc/0xda0
[ 46.994894] sch_direct_xmit+0x198/0xd08
[ 46.998827] __qdisc_run+0x37c/0x1dc0
[ 47.002500] __dev_queue_xmit+0x1528/0x21f8
[ 47.006692] dev_queue_xmit+0x24/0x30
[ 47.010366] neigh_resolve_output+0x37c/0x678
[ 47.014734] ip_finish_output2+0x598/0x2458
[ 47.018927] __ip_finish_output+0x300/0x730
[ 47.023118] ip_output+0x2e0/0x430
[ 47.026530] ip_local_out+0x90/0x140
[ 47.030117] igmpv3_sendpack+0x14c/0x228
[ 47.034049] igmpv3_send_cr+0x384/0x6b8
[ 47.037895] igmp_ifc_timer_expire+0x4c/0x118
[ 47.042262] call_timer_fn+0x1cc/0xbe8
[ 47.046021] __run_timers+0x4d8/0xb28
[ 47.049693] run_timer_softirq+0x24/0x40
[ 47.053626] __do_softirq+0x2c0/0x117c
[ 47.057387] irq_exit+0x2dc/0x388
[ 47.060715] __handle_domain_irq+0xb4/0x158
[ 47.064908] gic_handle_irq+0x58/0xb0
[ 47.068581] el0_irq_naked+0x50/0x5c
[ 47.072162]
[ 47.073665] Allocated by task 328:
[ 47.077083] save_stack+0x24/0xb0
[ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0
[ 47.084776] kasan_slab_alloc+0x14/0x20
[ 47.088622] kmem_cache_alloc+0x15c/0x468
[ 47.092643] __alloc_skb+0xa4/0x498
[ 47.096142] igmpv3_newpack+0x158/0xd78
[ 47.099987] add_grhead+0x210/0x288
[ 47.103485] add_grec+0x6b0/0xb70
[ 47.106811] igmpv3_send_cr+0x2e0/0x6b8
[ 47.110657] igmp_ifc_timer_expire+0x4c/0x118
[ 47.115027] call_timer_fn+0x1cc/0xbe8
[ 47.118785] __run_timers+0x4d8/0xb28
[ 47.122457] run_timer_softirq+0x24/0x40
[ 47.126389] __do_softirq+0x2c0/0x117c
[ 47.130142]
[ 47.131643] Freed by task 180:
[ 47.134712] save_stack+0x24/0xb0
[ 47.138041] __kasan_slab_free+0x108/0x180
[ 47.142146] kasan_slab_free+0x10/0x18
[ 47.145904] slab_free_freelist_hook+0xa4/0x1b0
[ 47.150444] kmem_cache_free+0x8c/0x528
[ 47.154292] kfree_skbmem+0x94/0x108
[ 47.157880] consume_skb+0x10c/0x5a8
[ 47.161466] __dev_kfree_skb_any+0x88/0xa0
[ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil]
[ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac]
[ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac]
[ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac]
[ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac]
[ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac]
[ 47.197859] process_one_work+0x7fc/0x1a80
[ 47.201965] worker_thread+0x31c/0xc40
[ 47.205726] kthread+0x2d8/0x370
[ 47.208967] ret_from_fork+0x10/0x18
[ 47.212546]
[ 47.214051] The buggy address belongs to the object at ffffff803f588280
[ 47.214051] which belongs to the cache skbuff_head_cache of size 208
[ 47.227086] The buggy address is located 104 bytes inside of
[ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350)
[ 47.238814] The buggy address belongs to the page:
[ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou
---truncated---
CVE-2022-50408
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory
Fixes the below NULL pointer dereference:
[...]
[ 14.471200] Call Trace:
[ 14.471562] <TASK>
[ 14.471882] lock_acquire+0x245/0x2e0
[ 14.472416] ? remove_wait_queue+0x12/0x50
[ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50
[ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50
[ 14.474318] ? remove_wait_queue+0x12/0x50
[ 14.474907] remove_wait_queue+0x12/0x50
[ 14.475480] sk_stream_wait_memory+0x20d/0x340
[ 14.476127] ? do_wait_intr_irq+0x80/0x80
[ 14.476704] do_tcp_sendpages+0x287/0x600
[ 14.477283] tcp_bpf_push+0xab/0x260
[ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500
[ 14.478461] ? __local_bh_enable_ip+0x77/0xe0
[ 14.479096] tcp_bpf_send_verdict+0x105/0x470
[ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0
[ 14.480311] sock_sendmsg+0x2d/0x40
[ 14.480822] ____sys_sendmsg+0x1b4/0x1c0
[ 14.481390] ? copy_msghdr_from_user+0x62/0x80
[ 14.482048] ___sys_sendmsg+0x78/0xb0
[ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150
[ 14.483215] ? __do_fault+0x2a/0x1a0
[ 14.483738] ? do_fault+0x15e/0x5d0
[ 14.484246] ? __handle_mm_fault+0x56b/0x1040
[ 14.484874] ? lock_is_held_type+0xdf/0x130
[ 14.485474] ? find_held_lock+0x2d/0x90
[ 14.486046] ? __sys_sendmsg+0x41/0x70
[ 14.486587] __sys_sendmsg+0x41/0x70
[ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350
[ 14.487822] do_syscall_64+0x34/0x80
[ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
The test scenario has the following flow:
thread1 thread2
----------- ---------------
tcp_bpf_sendmsg
tcp_bpf_send_verdict
tcp_bpf_sendmsg_redir sock_close
tcp_bpf_push_locked __sock_release
tcp_bpf_push //inet_release
do_tcp_sendpages sock->ops->release
sk_stream_wait_memory // tcp_close
sk_wait_event sk->sk_prot->close
release_sock(__sk);
***
lock_sock(sk);
__tcp_close
sock_orphan(sk)
sk->sk_wq = NULL
release_sock
****
lock_sock(__sk);
remove_wait_queue(sk_sleep(sk), &wait);
sk_sleep(sk)
//NULL pointer dereference
&rcu_dereference_raw(sk->sk_wq)->wait
While waiting for memory in thread1, the socket is released with its wait
queue because thread2 has closed it. This caused by tcp_bpf_send_verdict
didn't increase the f_count of psock->sk_redir->sk_socket->file in thread1.
We should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory
before accessing the wait queue.
CVE-2022-50409
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix error code path in acpi_ds_call_control_method()
A use-after-free in acpi_ps_parse_aml() after a failing invocaion of
acpi_ds_call_control_method() is reported by KASAN [1] and code
inspection reveals that next_walk_state pushed to the thread by
acpi_ds_create_walk_state() is freed on errors, but it is not popped
from the thread beforehand. Thus acpi_ds_get_current_walk_state()
called by acpi_ps_parse_aml() subsequently returns it as the new
walk state which is incorrect.
To address this, make acpi_ds_call_control_method() call
acpi_ds_pop_walk_state() to pop next_walk_state from the thread before
returning an error.
CVE-2022-50411
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails
fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when
fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed
&fcoe_sw_transport on fcoe_transports list. This causes panic when
reinserting module.
BUG: unable to handle page fault for address: fffffbfff82e2213
RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]
Call Trace:
<TASK>
do_one_initcall+0xd0/0x4e0
load_module+0x5eee/0x7210
...
CVE-2022-50414
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
device_add shall not be called multiple times as stated in its
documentation:
'Do not call this routine or device_register() more than once for
any device structure'
Syzkaller reports a bug as follows [1]:
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[...]
Call Trace:
<TASK>
__list_add include/linux/list.h:69 [inline]
list_add_tail include/linux/list.h:102 [inline]
kobj_kset_join lib/kobject.c:164 [inline]
kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214
kobject_add_varg lib/kobject.c:358 [inline]
kobject_add+0x150/0x1c0 lib/kobject.c:410
device_add+0x368/0x1e90 drivers/base/core.c:3452
hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53
hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799
hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110
hci_event_func net/bluetooth/hci_event.c:7440 [inline]
hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495
hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007
process_one_work+0x991/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
CVE-2022-50419
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()
When executing SMP task failed, the smp_execute_task_sg() calls del_timer()
to delete "slow_task->timer". However, if the timer handler
sas_task_internal_timedout() is running, the del_timer() in
smp_execute_task_sg() will not stop it and a UAF will happen. The process
is shown below:
(thread 1) | (thread 2)
smp_execute_task_sg() | sas_task_internal_timedout()
... |
del_timer() |
... | ...
sas_free_task(task) |
kfree(task->slow_task) //FREE|
| task->slow_task->... //USE
Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure
the timer handler have finished before the "task->slow_task" is
deallocated.
CVE-2022-50422
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()
There is an use-after-free reported by KASAN:
BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82
Read of size 1 at addr ffff888112afc460 by task modprobe/2111
CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
Call Trace:
<TASK>
kasan_report+0xae/0xe0
acpi_ut_remove_reference+0x3b/0x82
acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5
acpi_ds_store_object_to_local+0x15d/0x3a0
acpi_ex_store+0x78d/0x7fd
acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b
acpi_ps_parse_aml+0x217/0x8d5
...
</TASK>
The root cause of the problem is that the acpi_operand_object
is freed when acpi_ut_walk_package_tree() fails in
acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in
acpi_ut_copy_iobject_to_iobject(). The problem was introduced
by "8aa5e56eeb61" commit, this commit is to fix memory leak in
acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove
operation, lead to "acpi_operand_object" used after free.
Fix it by removing acpi_ut_remove_reference() in
acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()
is called to copy an internal package object into another internal
package object, when it fails, the memory of acpi_operand_object
should be freed by the caller.
CVE-2022-50423
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
kernfs: fix use-after-free in __kernfs_remove
Syzkaller managed to trigger concurrent calls to
kernfs_remove_by_name_ns() for the same file resulting in
a KASAN detected use-after-free. The race occurs when the root
node is freed during kernfs_drain().
To prevent this acquire an additional reference for the root
of the tree that is removed before calling __kernfs_remove().
Found by syzkaller with the following reproducer (slab_nomerge is
required):
syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0)
r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0)
close(r0)
pipe2(&(0x7f0000000140)={0xffffffffffffffff, <r1=>0xffffffffffffffff}, 0x800)
mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}})
Sample report:
==================================================================
BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline]
BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]
BUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369
Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857
CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433
kasan_report+0xa3/0x130 mm/kasan/report.c:495
kernfs_type include/linux/kernfs.h:335 [inline]
kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]
__kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369
__kernfs_remove fs/kernfs/dir.c:1356 [inline]
kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589
sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943
__kmem_cache_create+0x3e0/0x550 mm/slub.c:4899
create_cache mm/slab_common.c:229 [inline]
kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335
p9_client_create+0xd4d/0x1190 net/9p/client.c:993
v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408
v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126
legacy_get_tree+0xf1/0x200 fs/fs_context.c:610
vfs_get_tree+0x85/0x2e0 fs/super.c:1530
do_new_mount fs/namespace.c:3040 [inline]
path_mount+0x675/0x1d00 fs/namespace.c:3370
do_mount fs/namespace.c:3383 [inline]
__do_sys_mount fs/namespace.c:3591 [inline]
__se_sys_mount fs/namespace.c:3568 [inline]
__x64_sys_mount+0x282/0x300 fs/namespace.c:3568
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f725f983aed
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed
RDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000
RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000
R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000
</TASK>
Allocated by task 855:
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470
kasan_slab_alloc include/linux/kasan.h:224 [inline]
slab_post_alloc_hook mm/slab.h:7
---truncated---
CVE-2022-50432
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix possible memleak when register 'hctx' failed
There's issue as follows when do fault injection test:
unreferenced object 0xffff888132a9f400 (size 512):
comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2....
08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............
backtrace:
[<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0
[<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0
[<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230
[<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910
[<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0
[<00000000a2a34657>] 0xffffffffa2ad310f
[<00000000b173f718>] 0xffffffffa2af824a
[<0000000095a1dabb>] do_one_initcall+0x87/0x2a0
[<00000000f32fdf93>] do_init_module+0xdf/0x320
[<00000000cbe8541e>] load_module+0x3006/0x3390
[<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0
[<00000000a1a29ae8>] do_syscall_64+0x35/0x80
[<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Fault injection context as follows:
kobject_add
blk_mq_register_hctx
blk_mq_sysfs_register
blk_register_queue
device_add_disk
null_add_dev.part.0 [null_blk]
As 'blk_mq_register_hctx' may already add some objects when failed halfway,
but there isn't do fallback, caller don't know which objects add failed.
To solve above issue just do fallback when add objects failed halfway in
'blk_mq_register_hctx'.
CVE-2022-50434
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid crash when inline data creation follows DIO write
When inode is created and written to using direct IO, there is nothing
to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets
truncated later to say 1 byte and written using normal write, we will
try to store the data as inline data. This confuses the code later
because the inode now has both normal block and inline data allocated
and the confusion manifests for example as:
kernel BUG at fs/ext4/inode.c:2721!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
RIP: 0010:ext4_writepages+0x363d/0x3660
RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293
RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180
RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b
R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128
R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001
FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0
Call Trace:
<TASK>
do_writepages+0x397/0x640
filemap_fdatawrite_wbc+0x151/0x1b0
file_write_and_wait_range+0x1c9/0x2b0
ext4_sync_file+0x19e/0xa00
vfs_fsync_range+0x17b/0x190
ext4_buffered_write_iter+0x488/0x530
ext4_file_write_iter+0x449/0x1b90
vfs_write+0xbcd/0xf40
ksys_write+0x198/0x2c0
__x64_sys_write+0x7b/0x90
do_syscall_64+0x3d/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing
direct IO write to a file.
CVE-2022-50435
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: lvds: fix PM usage counter unbalance in poweron
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
We fix it by replacing it with the newest pm_runtime_resume_and_get
to keep usage counter balanced.
CVE-2022-50443
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix resolving backrefs for inline extent followed by prealloc
If a file consists of an inline extent followed by a regular or prealloc
extent, then a legitimate attempt to resolve a logical address in the
non-inline region will result in add_all_parents reading the invalid
offset field of the inline extent. If the inline extent item is placed
in the leaf eb s.t. it is the first item, attempting to access the
offset field will not only be meaningless, it will go past the end of
the eb and cause this panic:
[17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8
[17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI
[17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199
[17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110
[17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202
[17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000
[17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001
[17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff
[17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918
[17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd
[17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000
[17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0
[17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[17.676034] PKRU: 55555554
[17.677004] Call Trace:
[17.677877] add_all_parents+0x276/0x480
[17.679325] find_parent_nodes+0xfae/0x1590
[17.680771] btrfs_find_all_leafs+0x5e/0xa0
[17.682217] iterate_extent_inodes+0xce/0x260
[17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50
[17.685597] ? iterate_inodes_from_logical+0xa1/0xd0
[17.687404] iterate_inodes_from_logical+0xa1/0xd0
[17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50
[17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190
[17.692946] btrfs_ioctl+0x104a/0x2f60
[17.694384] ? selinux_file_ioctl+0x182/0x220
[17.695995] ? __x64_sys_ioctl+0x84/0xc0
[17.697394] __x64_sys_ioctl+0x84/0xc0
[17.698697] do_syscall_64+0x33/0x40
[17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae
[17.701753] RIP: 0033:0x7f64e72761b7
[17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7
[17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003
[17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60
[17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001
[17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0
[17.724839] Modules linked in:
Fix the bug by detecting the inline extent item in add_all_parents and
skipping to the next extent item.
CVE-2022-50456
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()
Fix a NULL pointer crash that occurs when we are freeing the socket at the
same time we access it via sysfs.
The problem is that:
1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take
the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()
does a get on the "struct sock".
2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put
on the "struct socket" and that does __sock_release() which sets the
sock->ops to NULL.
3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then
call kernel_getpeername() which accesses the NULL sock->ops.
Above we do a get on the "struct sock", but we needed a get on the "struct
socket". Originally, we just held the frwd_lock the entire time but in
commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while
calling getpeername()") we switched to refcount based because the network
layer changed and started taking a mutex in that path, so we could no
longer hold the frwd_lock.
Instead of trying to maintain multiple refcounts, this just has us use a
mutex for accessing the socket in the interface code paths.
CVE-2022-50459
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix xid leak in cifs_flock()
If not flock, before return -ENOLCK, should free the xid,
otherwise, the xid will be leaked.
CVE-2022-50460
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
xhci: Remove device endpoints from bandwidth list when freeing the device
Endpoints are normally deleted from the bandwidth list when they are
dropped, before the virt device is freed.
If xHC host is dying or being removed then the endpoints aren't dropped
cleanly due to functions returning early to avoid interacting with a
non-accessible host controller.
So check and delete endpoints that are still on the bandwidth list when
freeing the virt device.
Solves a list_del corruption kernel crash when unbinding xhci-pci,
caused by xhci_mem_cleanup() when it later tried to delete already freed
endpoints from the bandwidth list.
This only affects hosts that use software bandwidth checking, which
currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
CVE-2022-50470
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()
If device_register() fails in cxl_register_afu|adapter(), the device
is not added, device_unregister() can not be called in the error path,
otherwise it will cause a null-ptr-deref because of removing not added
device.
As comment of device_register() says, it should use put_device() to give
up the reference in the error path. So split device_unregister() into
device_del() and put_device(), then goes to put dev when register fails.
CVE-2022-50481
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode
There are many places that will get unhappy (and crash) when ext4_iget()
returns a bad inode. However, if iget the boot loader inode, allows a bad
inode to be returned, because the inode may not be initialized. This
mechanism can be used to bypass some checks and cause panic. To solve this
problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag
we'd be returning bad inode from ext4_iget(), otherwise we always return
the error code if the inode is bad inode.(suggested by Jan Kara)
CVE-2022-50485
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix crash when I/O abort times out
While performing CPU hotplug, a crash with the following stack was seen:
Call Trace:
qla24xx_process_response_queue+0x42a/0x970 [qla2xxx]
qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx]
qla_nvme_post_cmd+0x166/0x240 [qla2xxx]
nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc]
blk_mq_dispatch_rq_list+0x17b/0x610
__blk_mq_sched_dispatch_requests+0xb0/0x140
blk_mq_sched_dispatch_requests+0x30/0x60
__blk_mq_run_hw_queue+0x35/0x90
__blk_mq_delay_run_hw_queue+0x161/0x180
blk_execute_rq+0xbe/0x160
__nvme_submit_sync_cmd+0x16f/0x220 [nvme_core]
nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics]
nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc]
nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc]
process_one_work+0x1e8/0x3c0
On abort timeout, completion was called without checking if the I/O was
already completed.
Verify that I/O and abort request are indeed outstanding before attempting
completion.
CVE-2022-50493
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
When CPU 0 is offline and intel_powerclamp is used to inject
idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687
caller is debug_smp_processor_id+0x17/0x20
CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
check_preemption_disabled+0xdd/0xe0
debug_smp_processor_id+0x17/0x20
powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]
...
...
Here CPU 0 is the control CPU by default and changed to the current CPU,
if CPU 0 offlined. This check has to be performed under cpus_read_lock(),
hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
[ rjw: Subject edits ]
CVE-2022-50494
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm cache: Fix UAF in destroy()
Dm_cache also has the same UAF problem when dm_resume()
and dm_destroy() are concurrent.
Therefore, cancelling timer again in destroy().
CVE-2022-50496
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: coda: Add check for dcoda_iram_alloc
As the coda_iram_alloc may return NULL pointer,
it should be better to check the return value
in order to avoid NULL poineter dereference,
same as the others.
CVE-2022-50501
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas: avoid scheduling in rtas_os_term()
It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0
[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0
[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4
[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68
[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50
[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0
[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0
[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0
[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420
[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200
Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.
CVE-2022-50504
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix pci device refcount leak in ppr_notifier()
As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it before returning from ppr_notifier()
to avoid refcount leak.
CVE-2022-50505
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: coda: Add check for kmalloc
As the kmalloc may return NULL pointer,
it should be better to check the return value
in order to avoid NULL poineter dereference,
same as the others.
CVE-2022-50509
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix invalid derefence of sb_lvbptr
I experience issues when putting a lkbsb on the stack and have sb_lvbptr
field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash
with the following kernel message, the dangled pointer is here
0xdeadbeef as example:
[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef
[ 102.749320] #PF: supervisor read access in kernel mode
[ 102.749323] #PF: error_code(0x0000) - not-present page
[ 102.749325] PGD 0 P4D 0
[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI
[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565
[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10
[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
[ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202
[ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040
[ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070
[ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001
[ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70
[ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001
[ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000
[ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0
[ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 102.749379] PKRU: 55555554
[ 102.749381] Call Trace:
[ 102.749382] <TASK>
[ 102.749383] ? send_args+0xb2/0xd0
[ 102.749389] send_common+0xb7/0xd0
[ 102.749395] _unlock_lock+0x2c/0x90
[ 102.749400] unlock_lock.isra.56+0x62/0xa0
[ 102.749405] dlm_unlock+0x21e/0x330
[ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]
[ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture]
[ 102.749419] ? preempt_count_sub+0xba/0x100
[ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture]
[ 102.786186] kthread+0x10a/0x130
[ 102.786581] ? kthread_complete_and_exit+0x20/0x20
[ 102.787156] ret_from_fork+0x22/0x30
[ 102.787588] </TASK>
[ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw
[ 102.792536] CR2: 00000000deadbeef
[ 102.792930] ---[ end trace 0000000000000000 ]---
This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags
is set when copying the lvbptr array instead of if it's just null which
fixes for me the issue.
I think this patch can fix other dlm users as well, depending how they
handle the init, freeing memory handling of sb_lvbptr and don't set
DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a
hidden issue all the time. However with checking on DLM_LKF_VALBLK the
user always need to provide a sb_lvbptr non-null value. There might be
more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and
non-null to report the user the way how DLM API is used is wrong but can
be added for later, this will only fix the current behaviour.
CVE-2022-50516
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()
In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,
sas_rphy_free() needs be called to free the resource allocated in
sas_end_device_alloc(). Otherwise a kernel crash will happen:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108
CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x54/0x3d0
lr : device_del+0x37c/0x3d0
Call trace:
device_del+0x54/0x3d0
attribute_container_class_device_del+0x28/0x38
transport_remove_classdev+0x6c/0x80
attribute_container_device_trigger+0x108/0x110
transport_remove_device+0x28/0x38
sas_rphy_remove+0x50/0x78 [scsi_transport_sas]
sas_port_delete+0x30/0x148 [scsi_transport_sas]
do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
device_for_each_child+0x68/0xb0
sas_remove_children+0x30/0x50 [scsi_transport_sas]
sas_rphy_remove+0x38/0x78 [scsi_transport_sas]
sas_port_delete+0x30/0x148 [scsi_transport_sas]
do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
device_for_each_child+0x68/0xb0
sas_remove_children+0x30/0x50 [scsi_transport_sas]
sas_remove_host+0x20/0x38 [scsi_transport_sas]
scsih_remove+0xd8/0x420 [mpt3sas]
Because transport_add_device() is not called when sas_rphy_add() fails, the
device is not added. When sas_rphy_remove() is subsequently called to
remove the device in the remove() path, a NULL pointer dereference happens.
CVE-2022-50532
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm thin: Use last transaction's pmd->root when commit failed
Recently we found a softlock up problem in dm thin pool btree lookup
code due to corrupted metadata:
Kernel panic - not syncing: softlockup: hung tasks
CPU: 7 PID: 2669225 Comm: kworker/u16:3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Workqueue: dm-thin do_worker [dm_thin_pool]
Call Trace:
<IRQ>
dump_stack+0x9c/0xd3
panic+0x35d/0x6b9
watchdog_timer_fn.cold+0x16/0x25
__run_hrtimer+0xa2/0x2d0
</IRQ>
RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]
__bufio_new+0x11f/0x4f0 [dm_bufio]
new_read+0xa3/0x1e0 [dm_bufio]
dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]
ro_step+0x63/0x100 [dm_persistent_data]
btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]
dm_btree_lookup+0x16f/0x210 [dm_persistent_data]
dm_thin_find_block+0x12c/0x210 [dm_thin_pool]
__process_bio_read_only+0xc5/0x400 [dm_thin_pool]
process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]
process_one_work+0x3c5/0x730
Following process may generate a broken btree mixed with fresh and
stale btree nodes, which could get dm thin trapped in an infinite loop
while looking up data block:
Transaction 1: pmd->root = A, A->B->C // One path in btree
pmd->root = X, X->Y->Z // Copy-up
Transaction 2: X,Z is updated on disk, Y write failed.
// Commit failed, dm thin becomes read-only.
process_bio_read_only
dm_thin_find_block
__find_block
dm_btree_lookup(pmd->root)
The pmd->root points to a broken btree, Y may contain stale node
pointing to any block, for example X, which gets dm thin trapped into
a dead loop while looking up Z.
Fix this by setting pmd->root in __open_metadata(), so that dm thin
will use the last transaction's pmd->root if commit failed.
Fetch a reproducer in [Link].
Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
CVE-2022-50534
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()
In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will
not be freed through rpi_firmware_delete(), fix this leak by calling
kfree() in the error path.
CVE-2022-50537
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: si470x: Fix use-after-free in si470x_int_in_callback()
syzbot reported use-after-free in si470x_int_in_callback() [1]. This
indicates that urb->context, which contains struct si470x_device
object, is freed when si470x_int_in_callback() is called.
The cause of this issue is that si470x_int_in_callback() is called for
freed urb.
si470x_usb_driver_probe() calls si470x_start_usb(), which then calls
usb_submit_urb() and si470x_start(). If si470x_start_usb() fails,
si470x_usb_driver_probe() doesn't kill urb, but it just frees struct
si470x_device object, as depicted below:
si470x_usb_driver_probe()
...
si470x_start_usb()
...
usb_submit_urb()
retval = si470x_start()
return retval
if (retval < 0)
free struct si470x_device object, but don't kill urb
This patch fixes this issue by killing urb when si470x_start_usb()
fails and urb is submitted. If si470x_start_usb() fails and urb is
not submitted, i.e. submitting usb fails, it just frees struct
si470x_device object.
CVE-2022-50542
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
xhci_alloc_stream_info() allocates stream context array for stream_info
->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,
stream_info->stream_ctx_array is not released, which will lead to a
memory leak.
We can fix it by releasing the stream_info->stream_ctx_array with
xhci_free_stream_ctx() on the error path to avoid the potential memory
leak.
CVE-2022-50544
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048):
comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)
hex dump (first 32 bytes):
00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................
08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815bcd82>] kmalloc_trace+0x22/0x60
[<ffffffff827e20ee>] phy_device_create+0x4e/0x90
[<ffffffff827e6072>] get_phy_device+0xd2/0x220
[<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0
[<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0
[<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040]
...
The problem occurs in probe process as follows:
r6040_init_one:
mdiobus_register
mdiobus_scan <- alloc and register phy_device,
the reference count of phy_device is 3
r6040_mii_probe
phy_connect <- connect to the first phy_device,
so the reference count of the first
phy_device is 4, others are 3
register_netdev <- fault inject succeeded, goto error handling path
// error handling path
err_out_mdio_unregister:
mdiobus_unregister(lp->mii_bus);
err_out_mdio:
mdiobus_free(lp->mii_bus); <- the reference count of the first
phy_device is 1, it is not released
and other phy_devices are released
// similarly, the remove process also has the same problem
The root cause is traced to the phy_device is not disconnected when
removes one r6040 device in r6040_remove_one() or on error handling path
after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet
device is connected to the first PHY device of mii_bus, in order to
notify the connected driver when the link status changes, which is the
default behavior of the PHY infrastructure to handle everything.
Therefore the phy_device should be disconnected when removes one r6040
device or on error handling path.
Fix it by adding phy_disconnect() when removes one r6040 device or on
error handling path after r6040_mii probed successfully.
CVE-2022-50545
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata
Following concurrent processes:
P1(drop cache) P2(kworker)
drop_caches_sysctl_handler
drop_slab
shrink_slab
down_read(&shrinker_rwsem) - LOCK A
do_shrink_slab
super_cache_scan
prune_icache_sb
dispose_list
evict
ext4_evict_inode
ext4_clear_inode
ext4_discard_preallocations
ext4_mb_load_buddy_gfp
ext4_mb_init_cache
ext4_read_block_bitmap_nowait
ext4_read_bh_nowait
submit_bh
dm_submit_bio
do_worker
process_deferred_bios
commit
metadata_operation_failed
dm_pool_abort_metadata
down_write(&pmd->root_lock) - LOCK B
__destroy_persistent_data_objects
dm_block_manager_destroy
dm_bufio_client_destroy
unregister_shrinker
down_write(&shrinker_rwsem)
thin_map |
dm_thin_find_block v
down_read(&pmd->root_lock) --> ABBA deadlock
, which triggers hung task:
[ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.
[ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910
[ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2
[ 76.978534] Workqueue: dm-thin do_worker
[ 76.978552] Call Trace:
[ 76.978564] __schedule+0x6ba/0x10f0
[ 76.978582] schedule+0x9d/0x1e0
[ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0
[ 76.978600] down_write+0xec/0x110
[ 76.978607] unregister_shrinker+0x2c/0xf0
[ 76.978616] dm_bufio_client_destroy+0x116/0x3d0
[ 76.978625] dm_block_manager_destroy+0x19/0x40
[ 76.978629] __destroy_persistent_data_objects+0x5e/0x70
[ 76.978636] dm_pool_abort_metadata+0x8e/0x100
[ 76.978643] metadata_operation_failed+0x86/0x110
[ 76.978649] commit+0x6a/0x230
[ 76.978655] do_worker+0xc6e/0xd90
[ 76.978702] process_one_work+0x269/0x630
[ 76.978714] worker_thread+0x266/0x630
[ 76.978730] kthread+0x151/0x1b0
[ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.
[ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910
[ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459
[ 76.982128] Call Trace:
[ 76.982139] __schedule+0x6ba/0x10f0
[ 76.982155] schedule+0x9d/0x1e0
[ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910
[ 76.982173] down_read+0x84/0x170
[ 76.982177] dm_thin_find_block+0x4c/0xd0
[ 76.982183] thin_map+0x201/0x3d0
[ 76.982188] __map_bio+0x5b/0x350
[ 76.982195] dm_submit_bio+0x2b6/0x930
[ 76.982202] __submit_bio+0x123/0x2d0
[ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0
[ 76.982222] submit_bio_noacct+0x389/0x770
[ 76.982227] submit_bio+0x50/0xc0
[ 76.982232] submit_bh_wbc+0x15e/0x230
[ 76.982238] submit_bh+0x14/0x20
[ 76.982241] ext4_read_bh_nowait+0xc5/0x130
[ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60
[ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0
[ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0
[ 76.982263] ext4_discard_preallocations+0x45d/0x830
[ 76.982274] ext4_clear_inode+0x48/0xf0
[ 76.982280] ext4_evict_inode+0xcf/0xc70
[ 76.982285] evict+0x119/0x2b0
[ 76.982290] dispose_list+0x43/0xa0
[ 76.982294] prune_icache_sb+0x64/0x90
[ 76.982298] super_cache_scan+0x155/0x210
[ 76.982303] do_shrink_slab+0x19e/0x4e0
[ 76.982310] shrink_slab+0x2bd/0x450
[ 76.982317] drop_slab+0xcc/0x1a0
[ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0
[ 76.982327] proc_sys_call_handler+0x1bc/0x300
[ 76.982331] proc_sys_write+0x17/0x20
[ 76.982334] vfs_write+0x3d3/0x570
[ 76.982342] ksys_write+0x73/0x160
[ 76.982347] __x64_sys_write+0x1e/0x30
[ 76.982352] do_syscall_64+0x35/0x80
[ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Funct
---truncated---
CVE-2022-50549
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()
This patch fixes a shift-out-of-bounds in brcmfmac that occurs in
BIT(chiprev) when a 'chiprev' provided by the device is too large.
It should also not be equal to or greater than BITS_PER_TYPE(u32)
as we do bitwise AND with a u32 variable and BIT(chiprev). The patch
adds a check that makes the function return NULL if that is the case.
Note that the NULL case is later handled by the bus-specific caller,
brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.
Found by a modified version of syzkaller.
UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
shift exponent 151055786 is too large for 64-bit type 'long unsigned int'
CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
dump_stack_lvl+0x57/0x7d
ubsan_epilogue+0x5/0x40
__ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb
? lock_chain_count+0x20/0x20
brcmf_fw_alloc_request.cold+0x19/0x3ea
? brcmf_fw_get_firmwares+0x250/0x250
? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0
brcmf_usb_get_fwname+0x114/0x1a0
? brcmf_usb_reset_resume+0x120/0x120
? number+0x6c4/0x9a0
brcmf_c_process_clm_blob+0x168/0x590
? put_dec+0x90/0x90
? enable_ptr_key_workfn+0x20/0x20
? brcmf_common_pd_remove+0x50/0x50
? rcu_read_lock_sched_held+0xa1/0xd0
brcmf_c_preinit_dcmds+0x673/0xc40
? brcmf_c_set_joinpref_default+0x100/0x100
? rcu_read_lock_sched_held+0xa1/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? lock_acquire+0x19d/0x4e0
? find_held_lock+0x2d/0x110
? brcmf_usb_deq+0x1cc/0x260
? mark_held_locks+0x9f/0xe0
? lockdep_hardirqs_on_prepare+0x273/0x3e0
? _raw_spin_unlock_irqrestore+0x47/0x50
? trace_hardirqs_on+0x1c/0x120
? brcmf_usb_deq+0x1a7/0x260
? brcmf_usb_rx_fill_all+0x5a/0xf0
brcmf_attach+0x246/0xd40
? wiphy_new_nm+0x1476/0x1d50
? kmemdup+0x30/0x40
brcmf_usb_probe+0x12de/0x1690
? brcmf_usbdev_qinit.constprop.0+0x470/0x470
usb_probe_interface+0x25f/0x710
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
? usb_match_id.part.0+0x88/0xc0
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
? driver_allows_async_probing+0x120/0x120
bus_for_each_drv+0x123/0x1a0
? bus_rescan_devices+0x20/0x20
? lockdep_hardirqs_on_prepare+0x273/0x3e0
? trace_hardirqs_on+0x1c/0x120
__device_attach+0x207/0x330
? device_bind_driver+0xb0/0xb0
? kobject_uevent_env+0x230/0x12c0
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
? __mutex_unlock_slowpath+0xe7/0x660
? __fw_devlink_link_to_suppliers+0x550/0x550
usb_set_configuration+0x984/0x1770
? kernfs_create_link+0x175/0x230
usb_generic_driver_probe+0x69/0x90
usb_probe_device+0x9c/0x220
really_probe+0x1be/0xa90
__driver_probe_device+0x2ab/0x460
driver_probe_device+0x49/0x120
__device_attach_driver+0x18a/0x250
? driver_allows_async_probing+0x120/0x120
bus_for_each_drv+0x123/0x1a0
? bus_rescan_devices+0x20/0x20
? lockdep_hardirqs_on_prepare+0x273/0x3e0
? trace_hardirqs_on+0x1c/0x120
__device_attach+0x207/0x330
? device_bind_driver+0xb0/0xb0
? kobject_uevent_env+0x230/0x12c0
bus_probe_device+0x1a2/0x260
device_add+0xa61/0x1ce0
? __fw_devlink_link_to_suppliers+0x550/0x550
usb_new_device.cold+0x463/0xf66
? hub_disconnect+0x400/0x400
? _raw_spin_unlock_irq+0x24/0x30
hub_event+0x10d5/0x3330
? hub_port_debounce+0x280/0x280
? __lock_acquire+0x1671/0x5790
? wq_calc_node_cpumask+0x170/0x2a0
? lock_release+0x640/0x640
? rcu_read_lock_sched_held+0xa1/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? lockdep_hardirqs_on_prepare+0x273/0x3e0
process_one_work+0x873/0x13e0
? lock_release+0x640/0x640
? pwq_dec_nr_in_flight+0x320/0x320
? rwlock_bug.part.0+0x90/0x90
worker_thread+0x8b/0xd10
? __kthread_parkme+0xd9/0x1d0
? pr
---truncated---
CVE-2022-50551
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm thin: Fix UAF in run_timer_softirq()
When dm_resume() and dm_destroy() are concurrent, it will
lead to UAF, as follows:
BUG: KASAN: use-after-free in __run_timers+0x173/0x710
Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0
<snip>
Call Trace:
<IRQ>
dump_stack_lvl+0x73/0x9f
print_report.cold+0x132/0xaa2
_raw_spin_lock_irqsave+0xcd/0x160
__run_timers+0x173/0x710
kasan_report+0xad/0x110
__run_timers+0x173/0x710
__asan_store8+0x9c/0x140
__run_timers+0x173/0x710
call_timer_fn+0x310/0x310
pvclock_clocksource_read+0xfa/0x250
kvm_clock_read+0x2c/0x70
kvm_clock_get_cycles+0xd/0x20
ktime_get+0x5c/0x110
lapic_next_event+0x38/0x50
clockevents_program_event+0xf1/0x1e0
run_timer_softirq+0x49/0x90
__do_softirq+0x16e/0x62c
__irq_exit_rcu+0x1fa/0x270
irq_exit_rcu+0x12/0x20
sysvec_apic_timer_interrupt+0x8e/0xc0
One of the concurrency UAF can be shown as below:
use free
do_resume |
__find_device_hash_cell |
dm_get |
atomic_inc(&md->holders) |
| dm_destroy
| __dm_destroy
| if (!dm_suspended_md(md))
| atomic_read(&md->holders)
| msleep(1)
dm_resume |
__dm_resume |
dm_table_resume_targets |
pool_resume |
do_waker #add delay work |
dm_put |
atomic_dec(&md->holders) |
| dm_table_destroy
| pool_dtr
| __pool_dec
| __pool_destroy
| destroy_workqueue
| kfree(pool) # free pool
time out
__do_softirq
run_timer_softirq # pool has already been freed
This can be easily reproduced using:
1. create thin-pool
2. dmsetup suspend pool
3. dmsetup resume pool
4. dmsetup remove_all # Concurrent with 3
The root cause of this UAF bug is that dm_resume() adds timer after
dm_destroy() skips cancelling the timer because of suspend status.
After timeout, it will call run_timer_softirq(), however pool has
already been freed. The concurrency UAF bug will happen.
Therefore, cancelling timer again in __pool_destroy().
CVE-2022-50563
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/netiucv: Fix return type of netiucv_tx()
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.ndo_start_xmit = netiucv_tx,
^~~~~~~~~~
->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() to
match the prototype's to resolve the warning and potential CFI failure,
should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
Additionally, while in the area, remove a comment block that is no
longer relevant.
CVE-2022-50564
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Update ipcomp_scratches with NULL when freed
Currently if ipcomp_alloc_scratches() fails to allocate memory
ipcomp_scratches holds obsolete address. So when we try to free the
percpu scratches using ipcomp_free_scratches() it tries to vfree non
existent vm area. Described below:
static void * __percpu *ipcomp_alloc_scratches(void)
{
...
scratches = alloc_percpu(void *);
if (!scratches)
return NULL;
ipcomp_scratches does not know about this allocation failure.
Therefore holding the old obsolete address.
...
}
So when we free,
static void ipcomp_free_scratches(void)
{
...
scratches = ipcomp_scratches;
Assigning obsolete address from ipcomp_scratches
if (!scratches)
return;
for_each_possible_cpu(i)
vfree(*per_cpu_ptr(scratches, i));
Trying to free non existent page, causing warning: trying to vfree
existent vm area.
...
}
Fix this breakage by updating ipcomp_scrtches with NULL when scratches
is freed
CVE-2022-50569
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure
Now that lockdep is staying enabled through our entire CI runs I started
seeing the following stack in generic/475
------------[ cut here ]------------
WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0
CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
Workqueue: btrfs-cache btrfs_work_helper
RIP: 0010:btrfs_discard_update_discardable+0x98/0xb0
RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831e
RBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010
R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80
FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0
Call Trace:
__btrfs_remove_free_space_cache+0x27/0x30
load_free_space_cache+0xad2/0xaf0
caching_thread+0x40b/0x650
? lock_release+0x137/0x2d0
btrfs_work_helper+0xf2/0x3e0
? lock_is_held_type+0xe2/0x140
process_one_work+0x271/0x590
? process_one_work+0x590/0x590
worker_thread+0x52/0x3b0
? process_one_work+0x590/0x590
kthread+0xf0/0x120
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x1f/0x30
This is the code
ctl = block_group->free_space_ctl;
discard_ctl = &block_group->fs_info->discard_ctl;
lockdep_assert_held(&ctl->tree_lock);
We have a temporary free space ctl for loading the free space cache in
order to avoid having allocations happening while we're loading the
cache. When we hit an error we free it all up, however this also calls
btrfs_discard_update_discardable, which requires
block_group->free_space_ctl->tree_lock to be held. However this is our
temporary ctl so this lock isn't held. Fix this by calling
__btrfs_remove_free_space_cache_locked instead so that we only clean up
the entries and do not mess with the discardable stats.
CVE-2022-50571
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
class: fix possible memory leak in __class_register()
If class_add_groups() returns error, the 'cp->subsys' need be
unregister, and the 'cp' need be freed.
We can not call kset_unregister() here, because the 'cls' will
be freed in callback function class_release() and it's also
freed in caller's error path, it will cause double free.
So fix this by calling kobject_del() and kfree_const(name) to
cleanup kobject. Besides, call kfree() to free the 'cp'.
Fault injection test can trigger this:
unreferenced object 0xffff888102fa8190 (size 8):
comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)
hex dump (first 8 bytes):
70 6b 74 63 64 76 64 00 pktcdvd.
backtrace:
[<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320
[<000000005e4d70bc>] kstrdup+0x3a/0x70
[<00000000c2e5e85a>] kstrdup_const+0x68/0x80
[<000000000049a8c7>] kvasprintf_const+0x10b/0x190
[<0000000029123163>] kobject_set_name_vargs+0x56/0x150
[<00000000747219c9>] kobject_set_name+0xab/0xe0
[<0000000005f1ea4e>] __class_register+0x15c/0x49a
unreferenced object 0xffff888037274000 (size 1024):
comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)
hex dump (first 32 bytes):
00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7....
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
backtrace:
[<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0
[<00000000ecf3dd95>] __class_register+0x86/0x49a
CVE-2022-50578
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hfs: fix OOB Read in __hfs_brec_find
Syzbot reported a OOB read bug:
==================================================================
BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190
fs/hfs/string.c:84
Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11
CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted
6.1.0-rc6-syzkaller-00308-g644e9524388a #0
Workqueue: writeback wb_workfn (flush-7:0)
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
print_address_description+0x74/0x340 mm/kasan/report.c:284
print_report+0x107/0x1f0 mm/kasan/report.c:395
kasan_report+0xcd/0x100 mm/kasan/report.c:495
hfs_strcmp+0x117/0x190 fs/hfs/string.c:84
__hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75
hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138
hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462
write_inode fs/fs-writeback.c:1440 [inline]
If the input inode of hfs_write_inode() is incorrect:
struct inode
struct hfs_inode_info
struct hfs_cat_key
struct hfs_name
u8 len # len is greater than HFS_NAMELEN(31) which is the
maximum length of an HFS filename
OOB read occurred:
hfs_write_inode()
hfs_brec_find()
__hfs_brec_find()
hfs_cat_keycmp()
hfs_strcmp() # OOB read occurred due to len is too large
Fix this by adding a Check on len in hfs_write_inode() before calling
hfs_brec_find().
CVE-2022-50581
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to potentially crash the system.
CVE-2023-0160
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
There is a use-after-free vulnerability in the Linux Kernel which can be exploited to achieve local privilege escalation. To reach the vulnerability kernel configuration flag CONFIG_TLS or CONFIG_XFRM_ESPINTCP has to be configured, but the operation does not require any privilege.
There is a use-after-free bug of icsk_ulp_data of a struct inet_connection_sock.
When CONFIG_TLS is enabled, user can install a tls context (struct tls_context) on a connected tcp socket. The context is not cleared if this socket is disconnected and reused as a listener. If a new socket is created from the listener, the context is inherited and vulnerable.
The setsockopt TCP_ULP operation does not require any privilege.
We recommend upgrading past commit 2c02d41d71f90a5168391b6a5f2954112ba2307c
CVE-2023-0461
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A memory leak flaw was found in the Linux kernel's Stream Control Transmission Protocol. This issue may occur when a user starts a malicious networking service and someone connects to this service. This could allow a local user to starve resources, causing a denial of service.
CVE-2023-1074
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A slab-out-of-bound read problem was found in brcmf_get_assoc_ies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info->req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service.
CVE-2023-1380
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A NULL pointer dereference was found In libssh during re-keying with algorithm guessing. This issue may allow an authenticated client to cause a denial of service.
CVE-2023-1667
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root.
We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.
CVE-2023-1829
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:suse-module-tools-12.13-3.11.1
important
A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices.
CVE-2023-1989
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem.
CVE-2023-1990
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
Heap buffer overflow in sqlite in Google Chrome prior to 112.0.5615.137 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)
CVE-2023-2137
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libsqlite3-0-3.50.2-9.41.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sqlite3-tcl-3.50.2-9.41.1
important
A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information.
CVE-2023-2162
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.
CVE-2023-2176
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in the`pki_verify_data_signature` function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value `rc,` which is initialized to SSH_ERROR and later rewritten to save the return value of the function call `pki_key_check_hash_compatible.` The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls `goto error` returning SSH_OK.
CVE-2023-2283
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition.
CVE-2023-23559
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:suse-module-tools-12.13-3.11.1
moderate
Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.
CVE-2023-24023
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.
CVE-2023-27043
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
A NULL pointer dereference flaw was found in the az6027 driver in drivers/media/usb/dev-usb/az6027.c in the Linux Kernel. The message from user space is not checked properly before transferring into the device. This flaw allows a local user to crash the system or potentially cause a denial of service.
CVE-2023-28328
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel.
CVE-2023-2860
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
CVE-2023-28746
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in drivers/bluetooth/hci_ldisc.c in the Linux kernel 6.2. In hci_uart_tty_ioctl, there is a race condition between HCIUARTSETPROTO and HCIUARTGETPROTO. HCI_UART_PROTO_SET is set before hu->proto is set. A NULL pointer dereference may occur.
CVE-2023-31083
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in drivers/mtd/ubi/cdev.c in the Linux kernel 6.2. There is a divide-by-zero error in do_div(sz,mtd->erasesize), used indirectly by ctrl_cdev_ioctl, when mtd->erasesize is 0.
CVE-2023-31085
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag().
CVE-2023-3111
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information.
CVE-2023-3567
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.
CVE-2023-35827
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service.
CVE-2023-3772
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.
CVE-2023-38469
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-client3-0.6.32-32.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-common3-0.6.32-32.33.1
moderate
A vulnerability was found in Avahi. A reachable assertion exists in the avahi_escape_label() function.
CVE-2023-38470
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-client3-0.6.32-32.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-common3-0.6.32-32.33.1
moderate
A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.
CVE-2023-38471
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-client3-0.6.32-32.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-common3-0.6.32-32.33.1
moderate
A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.
CVE-2023-38472
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-client3-0.6.32-32.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-common3-0.6.32-32.33.1
moderate
A vulnerability was found in Avahi. A reachable assertion exists in the avahi_alternative_host_name() function.
CVE-2023-38473
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-client3-0.6.32-32.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-common3-0.6.32-32.33.1
moderate
A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.
CVE-2023-39189
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol.
CVE-2023-39197
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation.
CVE-2023-39198
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In GNU tar before 1.35, mishandled extension attributes in a PAX archive can lead to an application crash in xheader.c.
CVE-2023-39804
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:tar-1.27.1-15.24.1
low
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-v20260125-x86-64:libprocps3-3.3.9-11.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:procps-3.3.9-11.33.1
low
An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as "not connected" and won't initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)
CVE-2023-40217
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
A flaw was found in Shim when an error happened while creating a new ESL variable. If Shim fails to create the new variable, it tries to print an error message to the user; however, the number of parameters used by the logging function doesn't match the format string used by it, leading to a crash under certain circumstances.
CVE-2023-40546
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:shim-15.8-25.30.1
moderate
A remote code execution vulnerability was found in Shim. The Shim boot support trusts attacker-controlled values when parsing an HTTP response. This flaw allows an attacker to craft a specific malicious HTTP request, leading to a completely controlled out-of-bounds write primitive and complete system compromise. This flaw is only exploitable during the early boot phase, an attacker needs to perform a Man-in-the-Middle or compromise the boot server to be able to exploit this vulnerability successfully.
CVE-2023-40547
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:shim-15.8-25.30.1
moderate
A buffer overflow was found in Shim in the 32-bit system. The overflow happens due to an addition operation involving a user-controlled value parsed from the PE binary being used by Shim. This value is further used for memory allocation operations, leading to a heap-based buffer overflow. This flaw causes memory corruption and can lead to a crash or data integrity issues during the boot phase.
CVE-2023-40548
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:shim-15.8-25.30.1
moderate
An out-of-bounds read flaw was found in Shim when it tried to validate the SBAT information. This issue may expose sensitive data during the system's boot phase.
CVE-2023-40550
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:shim-15.8-25.30.1
moderate
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.
We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.
CVE-2023-4244
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.
CVE-2023-42465
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sudo-1.8.27-4.54.1
important
A flaw was found in the IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service.
CVE-2023-42755
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
The DNS message parsing code in `named` includes a section whose computational complexity is overly high. It does not cause problems for typical DNS traffic, but crafted queries and responses may cause excessive CPU load on the affected `named` instance by exploiting this flaw. This issue affects both authoritative servers and recursive resolvers.
This issue affects BIND 9 versions 9.0.0 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.
CVE-2023-4408
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:bind-utils-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libbind9-161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libdns1110-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libirs161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisc1107-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccc161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccfg163-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:liblwres161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-bind-9.11.22-3.65.1
important
The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.
CVE-2023-44487
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libnghttp2-14-1.39.2-3.18.1
important
libxml2 through 2.11.5 has a use-after-free that can only occur after a certain memory allocation fails. This occurs in xmlUnlinkNode in tree.c. NOTE: the vendor's position is "I don't think these issues are critical enough to warrant a CVE ID ... because an attacker typically can't control when memory allocations fail."
CVE-2023-45322
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
moderate
urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.
CVE-2023-45803
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-urllib3-1.25.10-3.43.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-urllib3-1.25.10-3.43.1
moderate
MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field. NOTE: MiniZip is not a supported part of the zlib product. NOTE: pyminizip through 0.2.6 is also vulnerable because it bundles an affected zlib version, and exposes the applicable MiniZip code through its compress API.
CVE-2023-45853
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libz1-1.2.11-11.37.1
moderate
An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation.
CVE-2023-45862
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in lib/kobject.c in the Linux kernel before 6.2.3. With root access, an attacker can trigger a race condition that results in a fill_kobj_path out-of-bounds write.
CVE-2023-45863
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU.
CVE-2023-45871
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2023-45918
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libncurses5-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libncurses6-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:ncurses-utils-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:terminfo-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:terminfo-base-5.9-88.1
low
This flaw allows a malicious HTTP server to set "super cookies" in curl that
are then passed back to more origins than what is otherwise allowed or
possible. This allows a site to set cookies that then would get sent to
different and unrelated sites and domains.
It could do this by exploiting a mixed case flaw in curl's function that
verifies a given cookie domain against the Public Suffix List (PSL). For
example a cookie could be set with `domain=co.UK` when the URL used a lower
case hostname `curl.co.uk`, even though `co.uk` is listed as a PSL domain.
CVE-2023-46218
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
When saving HSTS data to an excessively long file name, curl could end up
removing all contents, making subsequent requests using that file unaware of
the HSTS status they should otherwise use.
CVE-2023-46219
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
Vim is an improved version of the good old UNIX editor Vi. Heap-use-after-free in memory allocated in the function `ga_grow_inner` in in the file `src/alloc.c` at line 748, which is freed in the file `src/ex_docmd.c` in the function `do_cmdline` at line 1010 and then used again in `src/cmdhist.c` at line 759. When using the `:history` command, it's possible that the provided argument overflows the accepted value. Causing an Integer Overflow and potentially later an use-after-free. This vulnerability has been patched in version 9.0.2068.
CVE-2023-46246
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.
CVE-2023-46343
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Transmit requests in Xen's virtual network protocol can consist of
multiple parts. While not really useful, except for the initial part
any of them may be of zero length, i.e. carry no data at all. Besides a
certain initial portion of the to be transferred data, these parts are
directly translated into what Linux calls SKB fragments. Such converted
request parts can, when for a particular SKB they are all of length
zero, lead to a de-reference of NULL in core networking code.
CVE-2023-46838
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.
CVE-2023-47233
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Use After Free in GitHub repository vim/vim prior to 9.0.1857.
CVE-2023-4750
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
important
Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2023-48231
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Vim is an open source command line text editor. A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2023-48232
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Vim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2023-48233
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2023-48234
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause an
overflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2023-48235
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values larger
than MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2023-48236
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2023-48237
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Vim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.
CVE-2023-48706
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.
CVE-2023-48795
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:openssh-7.2p2-81.34.1
important
CVE-2023-4881 was wrongly assigned to a bug that was deemed to be a non-security issue by the Linux kernel security team.
CVE-2023-4881
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.
CVE-2023-50387
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:bind-utils-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libbind9-161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libdns1110-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libirs161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisc1107-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccc161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccfg163-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:liblwres161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-bind-9.11.22-3.65.1
important
NCurse v6.4-20230418 was discovered to contain a segmentation fault via the component _nc_wrap_entry().
CVE-2023-50495
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libncurses5-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libncurses6-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:ncurses-utils-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:terminfo-5.9-88.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:terminfo-base-5.9-88.1
moderate
A flaw was found in the python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
CVE-2023-50782
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
moderate
The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.
CVE-2023-50868
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:bind-utils-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libbind9-161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libdns1110-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libirs161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisc1107-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccc161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccfg163-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:liblwres161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-bind-9.11.22-3.65.1
important
In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.
CVE-2023-51042
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.
CVE-2023-51043
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name.
CVE-2023-51385
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:openssh-7.2p2-81.34.1
moderate
bt_sock_recvmsg in net/bluetooth/af_bluetooth.c in the Linux kernel through 6.6.8 has a use-after-free because of a bt_sock_ioctl race condition.
CVE-2023-51779
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.
CVE-2023-51780
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.
CVE-2023-51782
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.
CVE-2023-52340
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.
CVE-2023-52425
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
libexpat through 2.5.0 allows recursive XML Entity Expansion if XML_DTD is undefined at compile time.
CVE-2023-52426
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.
CVE-2023-52429
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2_parse_contexts()
Validate offsets and lengths before dereferencing create contexts in
smb2_parse_contexts().
This fixes following oops when accessing invalid create contexts from
server:
BUG: unable to handle page fault for address: ffff8881178d8cc3
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 4a01067 P4D 4a01067 PUD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]
Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00
00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7
7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00
RSP: 0018:ffffc900007939e0 EFLAGS: 00010216
RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90
RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000
RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000
R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000
R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22
FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x181/0x480
? search_module_extables+0x19/0x60
? srso_alias_return_thunk+0x5/0xfbef5
? exc_page_fault+0x1b6/0x1c0
? asm_exc_page_fault+0x26/0x30
? smb2_parse_contexts+0xa0/0x3a0 [cifs]
SMB2_open+0x38d/0x5f0 [cifs]
? smb2_is_path_accessible+0x138/0x260 [cifs]
smb2_is_path_accessible+0x138/0x260 [cifs]
cifs_is_path_remote+0x8d/0x230 [cifs]
cifs_mount+0x7e/0x350 [cifs]
cifs_smb3_do_mount+0x128/0x780 [cifs]
smb3_get_tree+0xd9/0x290 [cifs]
vfs_get_tree+0x2c/0x100
? capable+0x37/0x70
path_mount+0x2d7/0xb80
? srso_alias_return_thunk+0x5/0xfbef5
? _raw_spin_unlock_irqrestore+0x44/0x60
__x64_sys_mount+0x11a/0x150
do_syscall_64+0x47/0xf0
entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f8737657b1e
CVE-2023-52434
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: prevent mss overflow in skb_segment()
Once again syzbot is able to crash the kernel in skb_segment() [1]
GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :
mss = mss * partial_segs;
65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.
Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.
[1]
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
__skb_gso_segment+0x339/0x710 net/core/gso.c:124
skb_gso_segment include/net/gso.h:83 [inline]
validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x257/0x380 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
__sys_sendto+0x255/0x340 net/socket.c:2190
__do_sys_sendto net/socket.c:2202 [inline]
__se_sys_sendto net/socket.c:2198 [inline]
__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f8692032aa9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R0
---truncated---
CVE-2023-52435
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
apparmor: avoid crash when parsed profile name is empty
When processing a packed profile in unpack_profile() described like
"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().
aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
<TASK>
? strlen+0x1e/0xa0
aa_policy_init+0x1bb/0x230
aa_alloc_profile+0xb1/0x480
unpack_profile+0x3bc/0x4960
aa_unpack+0x309/0x15e0
aa_replace_profiles+0x213/0x33c0
policy_update+0x261/0x370
profile_replace+0x20e/0x2a0
vfs_write+0x2af/0xe00
ksys_write+0x126/0x250
do_syscall_64+0x46/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
</TASK>
---[ end trace 0000000000000000 ]---
RIP: 0010:strlen+0x1e/0xa0
It seems such behaviour of aa_splitn_fqname() is expected and checked in
other places where it is called (e.g. aa_remove_profiles). Well, there
is an explicit comment "a ns name without a following profile is allowed"
inside.
AFAICS, nothing can prevent unpacked "name" to be in form like
":samba-dcerpcd" - it is passed from userspace.
Deny the whole profile set replacement in such case and inform user with
EPROTO and an explaining message.
Found by Linux Verification Center (linuxtesting.org).
CVE-2023-52443
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix use after free on context disconnection
Upon module load, a kthread is created targeting the
pvr2_context_thread_func function, which may call pvr2_context_destroy
and thus call kfree() on the context object. However, that might happen
before the usb hub_event handler is able to notify the driver. This
patch adds a sanity check before the invalid read reported by syzbot,
within the context disconnection call stack.
CVE-2023-52445
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
'gluebi->desc' in gluebi_read().
ubi_gluebi_init
ubi_register_volume_notifier
ubi_enumerate_volumes
ubi_notify_all
gluebi_notify nb->notifier_call()
gluebi_create
mtd_device_register
mtd_device_parse_register
add_mtd_device
blktrans_notify_add not->add()
ftl_add_mtd tr->add_mtd()
scan_header
mtd_read
mtd_read_oob
mtd_read_oob_std
gluebi_read mtd->read()
gluebi->desc - NULL
Detailed reproduction information available at the Link [1],
In the normal case, obtain gluebi->desc in the gluebi_get_device(),
and access gluebi->desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.
The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME.
CVE-2023-52449
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/memhp: Fix access beyond end of drmem array
dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
last valid entry in the array. The debug message at the end of the
function then dereferences this pointer:
pr_debug("Failed to hot-remove memory at %llx\n",
lmb->base_addr);
This was found by inspection and confirmed with KASAN:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
==================================================================
BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
Read of size 8 at addr c000000364e97fd0 by task bash/949
dump_stack_lvl+0xa4/0xfc (unreliable)
print_report+0x214/0x63c
kasan_report+0x140/0x2e0
__asan_load8+0xa8/0xe0
dlpar_memory+0x298/0x1658
handle_dlpar_errorlog+0x130/0x1d0
dlpar_store+0x18c/0x3e0
kobj_attr_store+0x68/0xa0
sysfs_kf_write+0xc4/0x110
kernfs_fop_write_iter+0x26c/0x390
vfs_write+0x2d4/0x4e0
ksys_write+0xac/0x1a0
system_call_exception+0x268/0x530
system_call_vectored_common+0x15c/0x2ec
Allocated by task 1:
kasan_save_stack+0x48/0x80
kasan_set_track+0x34/0x50
kasan_save_alloc_info+0x34/0x50
__kasan_kmalloc+0xd0/0x120
__kmalloc+0x8c/0x320
kmalloc_array.constprop.0+0x48/0x5c
drmem_init+0x2a0/0x41c
do_one_initcall+0xe0/0x5c0
kernel_init_freeable+0x4ec/0x5a0
kernel_init+0x30/0x1e0
ret_from_kernel_user_thread+0x14/0x1c
The buggy address belongs to the object at c000000364e80000
which belongs to the cache kmalloc-128k of size 131072
The buggy address is located 0 bytes to the right of
allocated 98256-byte region [c000000364e80000, c000000364e97fd0)
==================================================================
pseries-hotplug-mem: Failed to hot-remove memory at 0
Log failed lookups with a separate message and dereference the
cursor only when it points to a valid entry.
CVE-2023-52451
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
EDAC/thunderx: Fix possible out-of-bounds string access
Enabling -Wstringop-overflow globally exposes a warning for a common bug
in the usage of strncat():
drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
1136 | strncat(msg, other, OCX_MESSAGE_SIZE);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
1145 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
1150 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
Apparently the author of this driver expected strncat() to behave the
way that strlcat() does, which uses the size of the destination buffer
as its third argument rather than the length of the source buffer. The
result is that there is no check on the size of the allocated buffer.
Change it to strlcat().
[ bp: Trim compiler output, fixup commit message. ]
CVE-2023-52464
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers/amd/pm: fix a use-after-free in kv_parse_power_table
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev->pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:
kv_parse_power_table
|-> kv_dpm_init
|-> kv_dpm_sw_init
|-> kv_dpm_fini
The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
first free in kv_parse_power_table and causes a use-after-free bug.
CVE-2023-52469
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()
check the alloc_workqueue return value in radeon_crtc_init()
to avoid null-ptr-deref.
CVE-2023-52470
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests
hfi1 user SDMA request processing has two bugs that can cause data
corruption for user SDMA requests that have multiple payload iovecs
where an iovec other than the tail iovec does not run up to the page
boundary for the buffer pointed to by that iovec.a
Here are the specific bugs:
1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len.
Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec
to the packet, even if some of those bytes are past
iovec->iov.iov_len and are thus not intended to be in the packet.
2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the
next iovec in user_sdma_request->iovs when the current iovec
is not PAGE_SIZE and does not contain enough data to complete the
packet. The transmitted packet will contain the wrong data from the
iovec pages.
This has not been an issue with SDMA packets from hfi1 Verbs or PSM2
because they only produce iovecs that end short of PAGE_SIZE as the tail
iovec of an SDMA request.
Fixing these bugs exposes other bugs with the SDMA pin cache
(struct mmu_rb_handler) that get in way of supporting user SDMA requests
with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So
this commit fixes those issues as well.
Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
payload user SDMA requests can hit:
1. Overlapping memory ranges in mmu_rb_handler will result in duplicate
pinnings.
2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),
the mmu_rb code (1) removes the existing entry under a lock, (2)
releases that lock, pins the new pages, (3) then reacquires the lock
to insert the extended mmu_rb_node.
If someone else comes in and inserts an overlapping entry between (2)
and (3), insert in (3) will fail.
The failure path code in this case unpins _all_ pages in either the
original mmu_rb_node or the new mmu_rb_node that was inserted between
(2) and (3).
3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is
incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node
could be evicted by another thread that gets mmu_rb_handler->lock and
checks mmu_rb_node->refcount before mmu_rb_node->refcount is
incremented.
4. Related to #2 above, SDMA request submission failure path does not
check mmu_rb_node->refcount before freeing mmu_rb_node object.
If there are other SDMA requests in progress whose iovecs have
pointers to the now-freed mmu_rb_node(s), those pointers to the
now-freed mmu_rb nodes will be dereferenced when those SDMA requests
complete.
CVE-2023-52474
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Input: powermate - fix use-after-free in powermate_config_complete
syzbot has found a use-after-free bug [1] in the powermate driver. This
happens when the device is disconnected, which leads to a memory free from
the powermate_device struct. When an asynchronous control message
completes after the kfree and its callback is invoked, the lock does not
exist anymore and hence the bug.
Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
device disconnection.
[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
CVE-2023-52475
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/lbr: Filter vsyscall addresses
We found that a panic can occur when a vsyscall is made while LBR sampling
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
call sequence can occur (most recent at top):
__insn_get_emulate_prefix()
insn_get_emulate_prefix()
insn_get_prefixes()
insn_get_opcode()
decode_branch_type()
get_branch_type()
intel_pmu_lbr_filter()
intel_pmu_handle_irq()
perf_event_nmi_handler()
Within __insn_get_emulate_prefix() at frame 0, a macro is called:
peek_nbyte_next(insn_byte_t, insn, i)
Within this macro, this dereference occurs:
(insn)->next_byte
Inspecting registers at this point, the value of the next_byte field is the
address of the vsyscall made, for example the location of the vsyscall
version of gettimeofday() at 0xffffffffff600000. The access to an address
in the vsyscall region will trigger an oops due to an unhandled page fault.
To fix the bug, filtering for vsyscalls can be done when
determining the branch type. This patch will return
a "none" branch if a kernel address if found to lie in the
vsyscall region.
CVE-2023-52476
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev->bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev->bos will be NULL and those accesses will result in a
crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.
CVE-2023-52477
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
races when it races with itself.
hidpp_connect_event() primarily runs from a workqueue but it also runs
on probe() and if a "device-connected" packet is received by the hw
when the thread running hidpp_connect_event() from probe() is waiting on
the hw, then a second thread running hidpp_connect_event() will be
started from the workqueue.
This opens the following races (note the below code is simplified):
1. Retrieving + printing the protocol (harmless race):
if (!hidpp->protocol_major) {
hidpp_root_get_protocol_version()
hidpp->protocol_major = response.rap.params[0];
}
We can actually see this race hit in the dmesg in the abrt output
attached to rhbz#2227968:
[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
Testing with extra logging added has shown that after this the 2 threads
take turn grabbing the hw access mutex (send_mutex) so they ping-pong
through all the other TOCTOU cases managing to hit all of them:
2. Updating the name to the HIDPP name (harmless race):
if (hidpp->name == hdev->name) {
...
hidpp->name = new_name;
}
3. Initializing the power_supply class for the battery (problematic!):
hidpp_initialize_battery()
{
if (hidpp->battery.ps)
return 0;
probe_battery(); /* Blocks, threads take turns executing this */
hidpp->battery.desc.properties =
devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
hidpp->battery.ps =
devm_power_supply_register(&hidpp->hid_dev->dev,
&hidpp->battery.desc, cfg);
}
4. Creating delayed input_device (potentially problematic):
if (hidpp->delayed_input)
return;
hidpp->delayed_input = hidpp_allocate_input(hdev);
The really big problem here is 3. Hitting the race leads to the following
sequence:
hidpp->battery.desc.properties =
devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
hidpp->battery.ps =
devm_power_supply_register(&hidpp->hid_dev->dev,
&hidpp->battery.desc, cfg);
...
hidpp->battery.desc.properties =
devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
hidpp->battery.ps =
devm_power_supply_register(&hidpp->hid_dev->dev,
&hidpp->battery.desc, cfg);
So now we have registered 2 power supplies for the same battery,
which looks a bit weird from userspace's pov but this is not even
the really big problem.
Notice how:
1. This is all devm-maganaged
2. The hidpp->battery.desc struct is shared between the 2 power supplies
3. hidpp->battery.desc.properties points to the result from the second
devm_kmemdup()
This causes a use after free scenario on USB disconnect of the receiver:
1. The last registered power supply class device gets unregistered
2. The memory from the last devm_kmemdup() call gets freed,
hidpp->battery.desc.properties now points to freed memory
3. The first registered power supply class device gets unregistered,
this involves sending a remove uevent to userspace which invokes
power_supply_uevent() to fill the uevent data
4. power_supply_uevent() uses hidpp->battery.desc.properties which
now points to freed memory leading to backtraces like this one:
Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
...
Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
...
Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30
Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0
Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0
Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680
Sep 22 20:01:35 eric kernel:
---truncated---
CVE-2023-52478
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/srso: Add SRSO mitigation for Hygon processors
Add mitigation for the speculative return stack overflow vulnerability
which exists on Hygon processors too.
CVE-2023-52482
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm: Don't unref the same fb many times by mistake due to deadlock handling
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it's still in use.
Reset fb to NULL once we've unreffed it to avoid doing it again
until we've done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit.
CVE-2023-52486
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO
The SC16IS7XX IC supports a burst mode to access the FIFOs where the
initial register address is sent ($00), followed by all the FIFO data
without having to resend the register address each time. In this mode, the
IC doesn't increment the register address for each R/W byte.
The regmap_raw_read() and regmap_raw_write() are functions which can
perform IO over multiple registers. They are currently used to read/write
from/to the FIFO, and although they operate correctly in this burst mode on
the SPI bus, they would corrupt the regmap cache if it was not disabled
manually. The reason is that when the R/W size is more than 1 byte, these
functions assume that the register address is incremented and handle the
cache accordingly.
Convert FIFO R/W functions to use the regmap _noinc_ versions in order to
remove the manual cache control which was a workaround when using the
_raw_ versions. FIFO registers are properly declared as volatile so
cache will not be used/updated for FIFO accesses.
CVE-2023-52488
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed
when we receive the response.
CVE-2023-52500
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.
Getting a reference on the socket found in a lookup while
holding a lock should happen before releasing the lock.
nfc_llcp_sock_get_sn() has a similar problem.
Finally nfc_llcp_recv_snl() needs to make sure the socket
found by nfc_llcp_sock_from_sn() does not disappear.
CVE-2023-52502
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: assert requested protocol is valid
The protocol is used in a bit mask to determine if the protocol is
supported. Assert the provided protocol is less than the maximum
defined so it doesn't potentially perform a shift-out-of-bounds and
provide a clearer error for undefined protocols vs unsupported ones.
CVE-2023-52507
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Do not call scsi_done() from srp_abort()
After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
callback, it performs one of the following actions:
* Call scsi_queue_insert().
* Call scsi_finish_command().
* Call scsi_eh_scmd_add().
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
the above actions would trigger a use-after-free. Hence remove the
scsi_done() call from srp_abort(). Keep the srp_free_req() call
before returning SUCCESS because we may not see the command again if
SUCCESS is returned.
CVE-2023-52515
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: llcp: Add lock when modifying device list
The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.
CVE-2023-52524
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()
Including the transhdrlen in length is a problem when the packet is
partially filled (e.g. something like send(MSG_MORE) happened previously)
when appending to an IPv4 or IPv6 packet as we don't want to repeat the
transport header or account for it twice. This can happen under some
circumstances, such as splicing into an L2TP socket.
The symptom observed is a warning in __ip6_append_data():
WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800
that occurs when MSG_SPLICE_PAGES is used to append more data to an already
partially occupied skbuff. The warning occurs when 'copy' is larger than
the amount of data in the message iterator. This is because the requested
length includes the transport header length when it shouldn't. This can be
triggered by, for example:
sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);
bind(sfd, ...); // ::1
connect(sfd, ...); // ::1 port 7
send(sfd, buffer, 4100, MSG_MORE);
sendfile(sfd, dfd, NULL, 1024);
Fix this by only adding transhdrlen into the length if the write queue is
empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.
l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds
the UDP packet itself.
CVE-2023-52527
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
syzbot reported the following uninit-value access issue:
=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
hub_port_connect drivers/usb/core/hub.c:5208 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
kthread+0x551/0x590 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Local variable ----buf.i87@smsc75xx_bind created at:
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, 'buf' is not properly filled.
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.
CVE-2023-52528
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix potential key use-after-free
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().
CVE-2023-52530
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: Fix a memory corruption issue
A few lines above, space is kzalloc()'ed for:
sizeof(struct iwl_nvm_data) +
sizeof(struct ieee80211_channel) +
sizeof(struct ieee80211_rate)
'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine.
At the end of this structure, there is the 'channels' flex array.
Each element is of type 'struct ieee80211_channel'.
So only 1 element is allocated in this array.
When doing:
mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels;
We point at the first element of the 'channels' flex array.
So this is fine.
However, when doing:
mvm->nvm_data->bands[0].bitrates =
(void *)((u8 *)mvm->nvm_data->channels + 1);
because of the "(u8 *)" cast, we add only 1 to the address of the beginning
of the flex array.
It is likely that we want point at the 'struct ieee80211_rate' allocated
just after.
Remove the spurious casting so that the pointer arithmetic works as
expected.
CVE-2023-52531
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix TX CQE error handling
For an unknown TX CQE error type (probably from a newer hardware),
still free the SKB, update the queue tail, etc., otherwise the
accounting will be wrong.
Also, TX errors can be triggered by injecting corrupted packets, so
replace the WARN_ONCE to ratelimited error logging.
CVE-2023-52532
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
team: fix null-ptr-deref when team device type is changed
Get a null-ptr-deref bug as follows with reproducer [1].
BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
<TASK>
? __die+0x24/0x70
? page_fault_oops+0x82/0x150
? exc_page_fault+0x69/0x150
? asm_exc_page_fault+0x26/0x30
? vlan_dev_hard_header+0x35/0x140 [8021q]
? vlan_dev_hard_header+0x8e/0x140 [8021q]
neigh_connected_output+0xb2/0x100
ip6_finish_output2+0x1cb/0x520
? nf_hook_slow+0x43/0xc0
? ip6_mtu+0x46/0x80
ip6_finish_output+0x2a/0xb0
mld_sendpack+0x18f/0x250
mld_ifc_work+0x39/0x160
process_one_work+0x1e6/0x3f0
worker_thread+0x4d/0x2f0
? __pfx_worker_thread+0x10/0x10
kthread+0xe5/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
[1]
$ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0
When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan->real_dev in vlan_dev_hard_header() because team device is not
a vlan device.
Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug.
CVE-2023-52574
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-52575
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix deadlock or deadcode of misusing dget()
The lock order is incorrect between denty and its parent, we should
always make sure that the parent get the lock first.
But since this deadcode is never used and the parent dir will always
be set from the callers, let's just remove it.
CVE-2023-52583
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: Add mutex lock in control vblank irq
Add a mutex lock to control vblank irq to synchronize vblank
enable/disable operations happening from different threads to prevent
race conditions while registering/unregistering the vblank irq callback.
v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a
parameter of dpu_encoder_phys.
-Switch from atomic refcnt to a simple int counter as mutex has
now been added
v3: Mistakenly did not change wording in last version. It is done now.
v2: Slightly changed wording of commit message
Patchwork: https://patchwork.freedesktop.org/patch/571854/
CVE-2023-52586
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
`priv->multicast_list` and we keep | remove_list, list)
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.
crash> bc 31
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
--
[exception RIP: ipoib_mcast_join_task+0x1b1]
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
work (&priv->mcast_task{,.work})
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
&mcast->list
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
mcast
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
dev priv (&priv->lock) &priv->multicast_list (aka head)
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <NMI exception stack> ---
#5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]
#6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
crash> rx ff646f199a8c7e68
ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work
crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000
(empty)
crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000
mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>,
mcast_mutex.owner.counter = 0xff1c69998efec000
crash> b 8
PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"
--
#3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646
#4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]
#5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]
#6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]
#7 [ff
---truncated---
CVE-2023-52587
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
reiserfs: Avoid touching renamed directory if parent does not change
The VFS will not be locking moved directory if its parent does not
change. Change reiserfs rename code to avoid touching renamed directory
if its parent does not change as without locking that can corrupt the
filesystem.
CVE-2023-52591
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
occurs when txs->cnt, data from a URB provided by a USB device, is
bigger than the size of the array txs->txstatus, which is
HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
handling code after the check. Make the function return if that is the
case.
Found by a modified version of syzkaller.
UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
index 13 is out of range for type '__wmi_event_txstatus [12]'
Call Trace:
ath9k_htc_txstatus
ath9k_wmi_event_tasklet
tasklet_action_common
__do_softirq
irq_exit_rxu
sysvec_apic_timer_interrupt
CVE-2023-52594
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: rt2x00: restart beacon queue when hardware reset
When a hardware reset is triggered, all registers are reset, so all
queues are forced to stop in hardware interface. However, mac80211
will not automatically stop the queue. If we don't manually stop the
beacon queue, the queue will be deadlocked and unable to start again.
This patch fixes the issue where Apple devices cannot connect to the
AP after calling ieee80211_restart_hw().
CVE-2023-52595
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: fix setting of fpc register
kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
(fpc) register of a guest cpu. The new value is tested for validity by
temporarily loading it into the fpc register.
This may lead to corruption of the fpc register of the host process:
if an interrupt happens while the value is temporarily loaded into the fpc
register, and within interrupt context floating point or vector registers
are used, the current fp/vx registers are saved with save_fpu_regs()
assuming they belong to user space and will be loaded into fp/vx registers
when returning to user space.
test_fp_ctl() restores the original user space / host process fpc register
value, however it will be discarded, when returning to user space.
In result the host process will incorrectly continue to run with the value
that was supposed to be used for a guest cpu.
Fix this by simply removing the test. There is another test right before
the SIE context is entered which will handles invalid values.
This results in a change of behaviour: invalid values will now be accepted
instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
given that this interface is most likely not used anymore, and this is in
addition the same behaviour implemented with the memory mapped interface
(replace invalid values with zero) - see sync_regs() in kvm-s390.c.
CVE-2023-52597
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/ptrace: handle setting of fpc register correctly
If the content of the floating point control (fpc) register of a traced
process is modified with the ptrace interface the new value is tested for
validity by temporarily loading it into the fpc register.
This may lead to corruption of the fpc register of the tracing process:
if an interrupt happens while the value is temporarily loaded into the
fpc register, and within interrupt context floating point or vector
registers are used, the current fp/vx registers are saved with
save_fpu_regs() assuming they belong to user space and will be loaded into
fp/vx registers when returning to user space.
test_fp_ctl() restores the original user space fpc register value, however
it will be discarded, when returning to user space.
In result the tracer will incorrectly continue to run with the value that
was supposed to be used for the traced process.
Fix this by saving fpu register contents with save_fpu_regs() before using
test_fp_ctl().
CVE-2023-52598
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-52605
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
CVE-2023-52607
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: scomp - fix req->dst buffer overflow
The req->dst buffer size should be checked before copying from the
scomp_scratch->dst to avoid req->dst buffer overflow problem.
CVE-2023-52612
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix buffer overflow in trans_stat_show
Fix buffer overflow in trans_stat_show().
Convert simple snprintf to the more secure scnprintf with size of
PAGE_SIZE.
Add condition checking if we are exceeding PAGE_SIZE and exit early from
loop. Also add at the end a warning that we exceeded PAGE_SIZE and that
stats is disabled.
Return -EFBIG in the case where we don't have enough space to write the
full transition table.
Also document in the ABI that this function can return -EFBIG error.
CVE-2023-52614
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
There is a dead-lock in the hwrng device read path. This triggers
when the user reads from /dev/hwrng into memory also mmap-ed from
/dev/hwrng. The resulting page fault triggers a recursive read
which then dead-locks.
Fix this by using a stack buffer when calling copy_to_user.
CVE-2023-52615
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pstore/ram: Fix crash when setting number of cpus to an odd number
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr of zone2 = BASE + zone_size*2
...
The address of zone1/3/5/7 will be mapped to non-alignment va.
Eventually crashes will occur when accessing these va.
So, use ALIGN_DOWN() to make sure the zone size is even
to avoid this bug.
CVE-2023-52619
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow timeout for anonymous sets
Never used from userspace, disallow these parameters.
CVE-2023-52620
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid online resizing failures due to oversized flex bg
When we online resize an ext4 filesystem with a oversized flexbg_size,
mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
mount $dev $dir
resize2fs $dev 16G
the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
<TASK>
__kmalloc_large_node+0xa2/0x200
__kmalloc+0x16e/0x290
ext4_resize_fs+0x481/0xd80
__ext4_ioctl+0x1616/0x1d90
ext4_ioctl+0x12/0x20
__x64_sys_ioctl+0xf0/0x150
do_syscall_64+0x3b/0x90
==================================================================
This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:
(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ~ 21845
And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed.
CVE-2023-52622
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a suspicious RCU usage warning
I received the following warning while running cthon against an ontap
server running pNFS:
[ 57.202521] =============================
[ 57.202522] WARNING: suspicious RCU usage
[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
[ 57.202525] -----------------------------
[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
[ 57.202527]
other info that might help us debug this:
[ 57.202528]
rcu_scheduler_active = 2, debug_locks = 1
[ 57.202529] no locks held by test5/3567.
[ 57.202530]
stack backtrace:
[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
[ 57.202536] Call Trace:
[ 57.202537] <TASK>
[ 57.202540] dump_stack_lvl+0x77/0xb0
[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0
[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202866] write_cache_pages+0x265/0x450
[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202913] do_writepages+0xd2/0x230
[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80
[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80
[ 57.202924] filemap_write_and_wait_range+0xd9/0x170
[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[ 57.202969] __se_sys_close+0x46/0xd0
[ 57.202972] do_syscall_64+0x68/0x100
[ 57.202975] ? do_syscall_64+0x77/0x100
[ 57.202976] ? do_syscall_64+0x77/0x100
[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 57.202982] RIP: 0033:0x7fe2b12e4a94
[ 57.202985] Code: 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 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3
[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94
[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003
[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49
[ 57.202993] R10: 00007f
---truncated---
CVE-2023-52623
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].
while true
do
echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
done
It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.
[1]
...
..
<idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428
<idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c
<idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428
kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227
vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532
vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428
xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428
[2]
9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a
[ 9436.261664][ C4] Mem abort info:
[ 9436.261666][ C4] ESR = 0x96000044
[ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits
[ 9436.261671][ C4] SET = 0, FnV = 0
[ 9436.261673][ C4] EA = 0, S1PTW = 0
[ 9436.261675][ C4] Data abort info:
[ 9436.261677][ C4] ISV = 0, ISS = 0x00000044
[ 9436.261680][ C4] CM = 0, WnR = 1
[ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges
[ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0
...
[ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1
[ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)
[ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
[ 9436.262161][ C4] pc : expire_timers+0x9c/0x438
[ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438
[ 9436.262168][ C4] sp : ffffffc010023dd0
[ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
[ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008
[ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280
[ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122
[ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80
[ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038
[ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201
[ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100
[ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
[ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff
[ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122
[ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
[ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101
[ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8
---truncated---
CVE-2023-52635
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: fix race during shadow creation
Right now it is possible to see gmap->private being zero in
kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the
fact that we add gmap->private == kvm after creation:
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
struct vsie_page *vsie_page)
{
[...]
gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);
if (IS_ERR(gmap))
return PTR_ERR(gmap);
gmap->private = vcpu->kvm;
Let children inherit the private field of the parent.
CVE-2023-52639
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
When QoS is disabled, the queue priority value will not map to the correct
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
is disabled to prevent trying to stop/wake a non-existent queue and failing
to stop/wake the actual queue instantiated.
Log of issue before change (with kernel parameter qos=0):
[ +5.112651] ------------[ cut here ]------------
[ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
[ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
[ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
[ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
[ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS
[ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
[ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
[ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
[ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
[ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
[ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
[ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
[ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
[ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
[ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
[ +0.000001] CS: 0010 DS: 0
---truncated---
CVE-2023-52644
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
aio: fix mremap after fork null-deref
Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced
a null-deref if mremap is called on an old aio mapping after fork as
mm->ioctx_table will be set to NULL.
[jmoyer@redhat.com: fix 80 column issue]
CVE-2023-52646
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: dsi: Add missing check for of_find_device_by_node
Add check for the return value of of_find_device_by_node() and return
the error if it fails in order to avoid NULL pointer dereference.
CVE-2023-52650
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NTB: fix possible name leak in ntb_register_device()
If device_register() fails in ntb_register_device(), the device name
allocated by dev_set_name() should be freed. As per the comment in
device_register(), callers should use put_device() to give up the
reference in the error path. So fix this by calling put_device() in the
error path so that the name can be freed in kobject_cleanup().
As a result of this, put_device() in the error path of
ntb_register_device() is removed and the actual error is returned.
[mani: reworded commit message]
CVE-2023-52652
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix a memleak in gss_import_v2_context
The ctx->mech_used.data allocated by kmemdup is not freed in neither
gss_import_v2_context nor it only caller gss_krb5_import_sec_context,
which frees ctx on error.
Thus, this patch reform the last call of gss_import_v2_context to the
gss_krb5_import_ctx_v2, preventing the memleak while keepping the return
formation.
CVE-2023-52653
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: aqc111: check packet for fixup for true limit
If a device sends a packet that is inbetween 0
and sizeof(u64) the value passed to skb_trim()
as length will wrap around ending up as some very
large value.
The driver will then proceed to parse the header
located at that position, which will either oops or
process some random value.
The fix is to check against sizeof(u64) rather than
0, which the driver currently does. The issue exists
since the introduction of the driver.
CVE-2023-52655
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: eliminate double free in error handling logic
Driver has a logic leak in ring data allocation/free,
where aq_ring_free could be called multiple times on same ring,
if system is under stress and got memory allocation error.
Ring pointer was used as an indicator of failure, but this is
not correct since only ring data is allocated/deallocated.
Ring itself is an array member.
Changing ring allocation functions to return error code directly.
This simplifies error handling and eliminates aq_ring_free
on higher layer.
CVE-2023-52664
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
When processing the last block, the s390 ctr code will always read
a whole block, even if there isn't a whole block of data left. Fix
this by using the actual length left and copy it into a buffer first
for processing.
CVE-2023-52669
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
CVE-2023-52675
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpit_update_residency() there is a possibility of overflow
in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
Change multiplication to mul_u32_u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-52683
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-52685
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_event_init()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
CVE-2023-52686
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix a double-free in si_dpm_init
When the allocation of
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
amdgpu_free_extended_power_table is called to free some fields of adev.
However, when the control flow returns to si_dpm_sw_init, it goes to
label dpm_failed and calls si_dpm_fini, which calls
amdgpu_free_extended_power_table again and free those fields again. Thus
a double-free is triggered.
CVE-2023-52691
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: check for error while searching for backlight device parent
If acpi_get_parent() called in acpi_video_dev_register_backlight()
fails, for example, because acpi_ut_acquire_mutex() fails inside
acpi_get_parent), this can lead to incorrect (uninitialized)
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
the parent pci device.
Check acpi_get_parent() result and set parent device only in case of success.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-52693
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_powercap_init()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
CVE-2023-52696
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
calipso: fix memory leak in netlbl_calipso_add_pass()
If IPv6 support is disabled at boot (ipv6.disable=1),
the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
and the netlbl_calipso_ops_get() function always returns NULL.
In this case, the netlbl_calipso_add_pass() function allocates memory
for the doi_def variable but doesn't free it with the calipso_doi_free().
BUG: memory leak
unreferenced object 0xffff888011d68180 (size 64):
comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
hex dump (first 32 bytes):
00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<...>] kmalloc include/linux/slab.h:552 [inline]
[<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
[<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
[<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
[<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
[<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
[<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
[<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
[<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
[<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
[<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
[<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
[<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
[<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
[<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
[<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
[<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
[<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller
[PM: merged via the LSM tree at Jakub Kicinski request]
CVE-2023-52698
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
syzbot reported that act_len in kalmia_send_init_packet() is
uninitialized when passing it to the first usb_bulk_msg error path. Jiri
Pirko noted that it's pointless to pass it in the error path, and that
the value that would be printed in the second error path would be the
value of act_len from the first call to usb_bulk_msg.[1]
With this in mind, let's just not pass act_len to the usb_bulk_msg error
paths.
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/
CVE-2023-52703
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_spi: fix error handling in mmc_spi_probe()
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
or it will cause null-ptr-deref, because of deleting a not added
device in mmc_remove_host().
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
and change the label 'fail_add_host' to 'fail_gpiod_request'.
CVE-2023-52708
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdio: fix possible resource leaks in some error paths
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
not release the resources, because the sdio function is not presented
in these two cases, it won't call of_node_put() or put_device().
To fix these leaks, make sdio_func_present() only control whether
device_del() needs to be called or not, then always call of_node_put()
and put_device().
In error case in sdio_init_func(), the reference of 'card->dev' is
not get, to avoid redundant put in sdio_free_func_cis(), move the
get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
it can keep the get/put function be balanced.
Without this patch, while doing fault inject test, it can get the
following leak reports, after this fix, the leak is gone.
unreferenced object 0xffff888112514000 (size 2048):
comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)
hex dump (first 32 bytes):
00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......
10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....
backtrace:
[<000000009e5931da>] kmalloc_trace+0x21/0x110
[<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core]
[<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core]
[<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
unreferenced object 0xffff888112511000 (size 2048):
comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)
hex dump (first 32 bytes):
00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......
10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....
backtrace:
[<000000009e5931da>] kmalloc_trace+0x21/0x110
[<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core]
[<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
CVE-2023-52730
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ceph: blocklist the kclient when receiving corrupted snap trace
When received corrupted snap trace we don't know what exactly has
happened in MDS side. And we shouldn't continue IOs and metadatas
access to MDS, which may corrupt or get incorrect contents.
This patch will just block all the further IO/MDS requests
immediately and then evict the kclient itself.
The reason why we still need to evict the kclient just after
blocking all the further IOs is that the MDS could revoke the caps
faster.
CVE-2023-52732
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: lock the inode in shared mode before starting fiemap
Currently fiemap does not take the inode's lock (VFS lock), it only locks
a file range in the inode's io tree. This however can lead to a deadlock
if we have a concurrent fsync on the file and fiemap code triggers a fault
when accessing the user space buffer with fiemap_fill_next_extent(). The
deadlock happens on the inode's i_mmap_lock semaphore, which is taken both
by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by
syzbot and triggers a trace like the following:
task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5293 [inline]
__schedule+0x995/0xe20 kernel/sched/core.c:6606
schedule+0xcb/0x190 kernel/sched/core.c:6682
wait_on_state fs/btrfs/extent-io-tree.c:707 [inline]
wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751
lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742
find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488
writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863
__extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174
extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091
extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211
do_writepages+0x3c3/0x680 mm/page-writeback.c:2581
filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388
__filemap_fdatawrite_range mm/filemap.c:421 [inline]
filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439
btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline]
start_ordered_ops fs/btrfs/file.c:1737 [inline]
btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839
generic_write_sync include/linux/fs.h:2885 [inline]
btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684
call_write_iter include/linux/fs.h:2189 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x7dc/0xc50 fs/read_write.c:584
ksys_write+0x177/0x2a0 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f7d4054e9b9
RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9
RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006
RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69
R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8
</TASK>
INFO: task syz-executor361:5697 blocked for more than 145 seconds.
Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5293 [inline]
__schedule+0x995/0xe20 kernel/sched/core.c:6606
schedule+0xcb/0x190 kernel/sched/core.c:6682
rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095
__down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260
btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526
do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
wp_page_shared+0x15e/0x380 mm/memory.c:3295
handle_pte_fault mm/memory.c:4949 [inline]
__handle_mm_fault mm/memory.c:5073 [inline]
handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219
do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428
handle_page_fault arch/x86/mm/fault.c:1519 [inline]
exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570
RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233
Code: 74 0a 89 (...)
RSP: 0018:ffffc9000570f330 EFLAGS: 000502
---truncated---
CVE-2023-52737
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix use-after-free in rdata->read_into_pages()
When the network status is unstable, use-after-free may occur when
read data from the server.
BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0
Call Trace:
<TASK>
dump_stack_lvl+0x38/0x4c
print_report+0x16f/0x4a6
kasan_report+0xb7/0x130
readpages_fill_pages+0x14c/0x7e0
cifs_readv_receive+0x46d/0xa40
cifs_demultiplex_thread+0x121c/0x1490
kthread+0x16b/0x1a0
ret_from_fork+0x2c/0x50
</TASK>
Allocated by task 2535:
kasan_save_stack+0x22/0x50
kasan_set_track+0x25/0x30
__kasan_kmalloc+0x82/0x90
cifs_readdata_direct_alloc+0x2c/0x110
cifs_readdata_alloc+0x2d/0x60
cifs_readahead+0x393/0xfe0
read_pages+0x12f/0x470
page_cache_ra_unbounded+0x1b1/0x240
filemap_get_pages+0x1c8/0x9a0
filemap_read+0x1c0/0x540
cifs_strict_readv+0x21b/0x240
vfs_read+0x395/0x4b0
ksys_read+0xb8/0x150
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Freed by task 79:
kasan_save_stack+0x22/0x50
kasan_set_track+0x25/0x30
kasan_save_free_info+0x2e/0x50
__kasan_slab_free+0x10e/0x1a0
__kmem_cache_free+0x7a/0x1a0
cifs_readdata_release+0x49/0x60
process_one_work+0x46c/0x760
worker_thread+0x2a4/0x6f0
kthread+0x16b/0x1a0
ret_from_fork+0x2c/0x50
Last potentially related work creation:
kasan_save_stack+0x22/0x50
__kasan_record_aux_stack+0x95/0xb0
insert_work+0x2b/0x130
__queue_work+0x1fe/0x660
queue_work_on+0x4b/0x60
smb2_readv_callback+0x396/0x800
cifs_abort_connection+0x474/0x6a0
cifs_reconnect+0x5cb/0xa50
cifs_readv_from_socket.cold+0x22/0x6c
cifs_read_page_from_socket+0xc1/0x100
readpages_fill_pages.cold+0x2f/0x46
cifs_readv_receive+0x46d/0xa40
cifs_demultiplex_thread+0x121c/0x1490
kthread+0x16b/0x1a0
ret_from_fork+0x2c/0x50
The following function calls will cause UAF of the rdata pointer.
readpages_fill_pages
cifs_read_page_from_socket
cifs_readv_from_socket
cifs_reconnect
__cifs_reconnect
cifs_abort_connection
mid->callback() --> smb2_readv_callback
queue_work(&rdata->work) # if the worker completes first,
# the rdata is freed
cifs_readv_complete
kref_put
cifs_readdata_release
kfree(rdata)
return rdata->... # UAF in readpages_fill_pages()
Similarly, this problem also occurs in the uncache_fill_pages().
Fix this by adjusts the order of condition judgment in the return
statement.
CVE-2023-52741
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: USB: Fix wrong-direction WARNING in plusb.c
The syzbot fuzzer detected a bug in the plusb network driver: A
zero-length control-OUT transfer was treated as a read instead of a
write. In modern kernels this error provokes a WARNING:
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411
usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
Modules linked in:
CPU: 1 PID: 4645 Comm: dhcpcd Not tainted
6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/12/2023
RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
...
Call Trace:
<TASK>
usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
__usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010
usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068
pl_vendor_req drivers/net/usb/plusb.c:60 [inline]
pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]
pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85
usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
__dev_open+0x297/0x4d0 net/core/dev.c:1417
__dev_change_flags+0x587/0x750 net/core/dev.c:8530
dev_change_flags+0x97/0x170 net/core/dev.c:8602
devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147
inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979
sock_do_ioctl+0xcc/0x230 net/socket.c:1169
sock_ioctl+0x1f8/0x680 net/socket.c:1286
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and
remove the USB_DIR_IN flag.
CVE-2023-52742
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ice: Do not use WQ_MEM_RECLAIM flag for workqueue
When both ice and the irdma driver are loaded, a warning in
check_flush_dependency is being triggered. This is due to ice driver
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
is not.
According to kernel documentation, this flag should be set if the
workqueue will be involved in the kernel's memory reclamation flow.
Since it is not, there is no need for the ice driver's WQ to have this
flag set so remove it.
Example trace:
[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
[ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
[ +0.000161] [last unloaded: bonding]
[ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
[ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[ +0.000003] Workqueue: ice ice_service_task [ice]
[ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
[ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
[ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
[ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
[ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
[ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
[ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
[ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
[ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
[ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
[ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ +0.000002] PKRU: 55555554
[ +0.000003] Call Trace:
[ +0.000002] <TASK>
[ +0.000003] __flush_workqueue+0x203/0x840
[ +0.000006] ? mutex_unlock+0x84/0xd0
[ +0.000008] ? __pfx_mutex_unlock+0x10/0x10
[ +0.000004] ? __pfx___flush_workqueue+0x10/0x10
[ +0.000006] ? mutex_lock+0xa3/0xf0
[ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]
[ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]
[ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]
[ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]
[ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
[ +0.000059] ? up_write+0x5c/0x90
[ +0.000005] irdma_remove+0x36/0x90 [irdma]
[ +0.000062] auxiliary_bus_remove+0x32/0x50
[ +0.000007] device_r
---truncated---
CVE-2023-52743
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Restore allocated resources on failed copyout
Fix a resource leak if an error occurs.
CVE-2023-52747
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down
(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()
to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData
while mounting and umounting
[ 816.251274] general protection fault, probably for non-canonical
address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
...
[ 816.260138] Call Trace:
[ 816.260329] <TASK>
[ 816.260499] ? die_addr+0x36/0x90
[ 816.260762] ? exc_general_protection+0x1b3/0x410
[ 816.261126] ? asm_exc_general_protection+0x26/0x30
[ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]
[ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]
[ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]
[ 816.262689] ? seq_read_iter+0x379/0x470
[ 816.262995] seq_read_iter+0x118/0x470
[ 816.263291] proc_reg_read_iter+0x53/0x90
[ 816.263596] ? srso_alias_return_thunk+0x5/0x7f
[ 816.263945] vfs_read+0x201/0x350
[ 816.264211] ksys_read+0x75/0x100
[ 816.264472] do_syscall_64+0x3f/0x90
[ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 816.265135] RIP: 0033:0x7fd5e669d381
CVE-2023-52752
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why & How]
Check whether assigned timing generator is NULL or not before
accessing its funcs to prevent NULL dereference.
CVE-2023-52753
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: imon: fix access to invalid resource for the second interface
imon driver probes two USB interfaces, and at the probe of the second
interface, the driver assumes blindly that the first interface got
bound with the same imon driver. It's usually true, but it's still
possible that the first interface is bound with another driver via a
malformed descriptor. Then it may lead to a memory corruption, as
spotted by syzkaller; imon driver accesses the data from drvdata as
struct imon_context object although it's a completely different one
that was assigned by another driver.
This patch adds a sanity check -- whether the first interface is
really bound with the imon driver or not -- for avoiding the problem
above at the probe time.
CVE-2023-52754
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when releasing mids
All release_mid() callers seem to hold a reference of @mid so there is
no need to call kref_put(&mid->refcount, __release_mid) under
@server->mid_lock spinlock. If they don't, then an use-after-free bug
would have occurred anyways.
By getting rid of such spinlock also fixes a potential deadlock as
shown below
CPU 0 CPU 1
------------------------------------------------------------------
cifs_demultiplex_thread() cifs_debug_data_proc_show()
release_mid()
spin_lock(&server->mid_lock);
spin_lock(&cifs_tcp_ses_lock)
spin_lock(&server->mid_lock)
__release_mid()
smb2_find_smb_tcon()
spin_lock(&cifs_tcp_ses_lock) *deadlock*
CVE-2023-52757
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-52759
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: fix implicit overflow on virtio_max_dma_size
The following codes have an implicit conversion from size_t to u32:
(u32)max_size = (size_t)virtio_max_dma_size(vdev);
This may lead overflow, Ex (size_t)4G -> (u32)0. Once
virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX
instead.
CVE-2023-52762
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: gspca: cpia1: shift-out-of-bounds in set_flicker
Syzkaller reported the following issue:
UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27
shift exponent 245 is too large for 32-bit type 'int'
When the value of the variable "sd->params.exposure.gain" exceeds the
number of bits in an integer, a shift-out-of-bounds error is reported. It
is triggered because the variable "currentexp" cannot be left-shifted by
more than the number of bits in an integer. In order to avoid invalid
range during left-shift, the conditional expression is added.
CVE-2023-52764
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: protect device queue against concurrent access
In dasd_profile_start() the amount of requests on the device queue are
counted. The access to the device queue is unprotected against
concurrent access. With a lot of parallel I/O, especially with alias
devices enabled, the device queue can change while dasd_profile_start()
is accessing the queue. In the worst case this leads to a kernel panic
due to incorrect pointer accesses.
Fix this by taking the device lock before accessing the queue and
counting the requests. Additionally the check for a valid profile data
pointer can be done earlier to avoid unnecessary locking in a hot path.
CVE-2023-52774
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: config: fix iteration issue in 'usb_get_bos_descriptor()'
The BOS descriptor defines a root descriptor and is the base descriptor for
accessing a family of related descriptors.
Function 'usb_get_bos_descriptor()' encounters an iteration issue when
skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
the same descriptor being read repeatedly.
To address this issue, a 'goto' statement is introduced to ensure that the
pointer and the amount read is updated correctly. This ensures that the
function iterates to the next descriptor instead of reading the same
descriptor repeatedly.
CVE-2023-52781
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bonding: stop the device in bond_setup_by_slave()
Commit 9eed321cde22 ("net: lapbether: only support ethernet devices")
has been able to keep syzbot away from net/lapb, until today.
In the following splat [1], the issue is that a lapbether device has
been created on a bonding device without members. Then adding a non
ARPHRD_ETHER member forced the bonding master to change its type.
The fix is to make sure we call dev_close() in bond_setup_by_slave()
so that the potential linked lapbether devices (or any other devices
having assumptions on the physical device) are removed.
A similar bug has been addressed in commit 40baec225765
("bonding: fix panic on non-ARPHRD_ETHER enslave failure")
[1]
skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0
kernel BUG at net/core/skbuff.c:192 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_panic net/core/skbuff.c:188 [inline]
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202
lr : skb_panic net/core/skbuff.c:188 [inline]
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202
sp : ffff800096a06aa0
x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000
x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea
x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140
x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100
x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001
x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00
x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c
x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086
Call trace:
skb_panic net/core/skbuff.c:188 [inline]
skb_under_panic+0x13c/0x140 net/core/skbuff.c:202
skb_push+0xf0/0x108 net/core/skbuff.c:2446
ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384
dev_hard_header include/linux/netdevice.h:3136 [inline]
lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257
lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447
lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149
lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251
__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326
lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492
notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93
raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461
call_netdevice_notifiers_info net/core/dev.c:1970 [inline]
call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]
call_netdevice_notifiers net/core/dev.c:2022 [inline]
__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508
dev_close_many+0x1e0/0x470 net/core/dev.c:1559
dev_close+0x174/0x250 net/core/dev.c:1585
lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466
notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93
raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461
call_netdevice_notifiers_info net/core/dev.c:1970 [inline]
call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]
call_netdevice_notifiers net/core/dev.c:2022 [inline]
__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508
dev_close_many+0x1e0/0x470 net/core/dev.c:1559
dev_close+0x174/0x250 net/core/dev.c:1585
bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332
bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539
dev_ifsioc+0x754/0x9ac
dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786
sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217
sock_ioctl+0x4e8/0x834 net/socket.c:1322
vfs_ioctl fs/ioctl.c:51 [inline]
__do_
---truncated---
CVE-2023-52784
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: add ipvlan_route_v6_outbound() helper
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving
the flowi6 struct used for the route lookup in an non inlined
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses
setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
stack guard page: 0000 [#1] SMP KASAN
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<#DF>
</#DF>
<TASK>
[<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
[<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline]
[<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
[<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline]
[<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline]
[<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline]
[<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632
[<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306
[<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline]
[<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221
[<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606
[<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline]
[<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116
[<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638
[<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651
[<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline]
[<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]
[<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]
[<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
[<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677
[<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229
[<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline]
[<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline]
[<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660
[<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
[<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline]
[<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline]
[<f
---truncated---
CVE-2023-52796
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()
workqueue,which takes care about pipefs superblock locking.
In some special scenarios, when kernel frees the pipefs sb of the
current client and immediately alloctes a new pipefs sb,
rpc_remove_pipedir function would misjudge the existence of pipefs
sb which is not the one it used to hold. As a result,
the rpc_remove_pipedir would clean the released freed pipefs dentries.
To fix this issue, rpc_remove_pipedir should check whether the
current pipefs sb is consistent with the original pipefs sb.
This error can be catched by KASAN:
=========================================================
[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200
[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503
[ 250.500549] Workqueue: events rpc_free_client_work
[ 250.501001] Call Trace:
[ 250.502880] kasan_report+0xb6/0xf0
[ 250.503209] ? dget_parent+0x195/0x200
[ 250.503561] dget_parent+0x195/0x200
[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10
[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90
[ 250.504781] rpc_remove_client_dir+0xf5/0x150
[ 250.505195] rpc_free_client_work+0xe4/0x230
[ 250.505598] process_one_work+0x8ee/0x13b0
...
[ 22.039056] Allocated by task 244:
[ 22.039390] kasan_save_stack+0x22/0x50
[ 22.039758] kasan_set_track+0x25/0x30
[ 22.040109] __kasan_slab_alloc+0x59/0x70
[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240
[ 22.040889] __d_alloc+0x31/0x8e0
[ 22.041207] d_alloc+0x44/0x1f0
[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140
[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110
[ 22.042459] rpc_create_client_dir+0x34/0x150
[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0
[ 22.043284] rpc_client_register+0x136/0x4e0
[ 22.043689] rpc_new_client+0x911/0x1020
[ 22.044057] rpc_create_xprt+0xcb/0x370
[ 22.044417] rpc_create+0x36b/0x6c0
...
[ 22.049524] Freed by task 0:
[ 22.049803] kasan_save_stack+0x22/0x50
[ 22.050165] kasan_set_track+0x25/0x30
[ 22.050520] kasan_save_free_info+0x2b/0x50
[ 22.050921] __kasan_slab_free+0x10e/0x1a0
[ 22.051306] kmem_cache_free+0xa5/0x390
[ 22.051667] rcu_core+0x62c/0x1930
[ 22.051995] __do_softirq+0x165/0x52a
[ 22.052347]
[ 22.052503] Last potentially related work creation:
[ 22.052952] kasan_save_stack+0x22/0x50
[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0
[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0
[ 22.054209] dentry_free+0xb2/0x140
[ 22.054540] __dentry_kill+0x3be/0x540
[ 22.054900] shrink_dentry_list+0x199/0x510
[ 22.055293] shrink_dcache_parent+0x190/0x240
[ 22.055703] do_one_tree+0x11/0x40
[ 22.056028] shrink_dcache_for_umount+0x61/0x140
[ 22.056461] generic_shutdown_super+0x70/0x590
[ 22.056879] kill_anon_super+0x3a/0x60
[ 22.057234] rpc_kill_sb+0x121/0x200
CVE-2023-52803
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
fc_lport_ptp_setup() did not check the return value of fc_rport_create()
which can return NULL and would cause a NULL pointer dereference. Address
this issue by checking return value of fc_rport_create() and log error
message on fc_rport_create() failed.
CVE-2023-52809
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Fix hungtask for PADATA_RESET
We found a hungtask bug in test_aead_vec_cfg as follows:
INFO: task cryptomgr_test:391009 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call trace:
__switch_to+0x98/0xe0
__schedule+0x6c4/0xf40
schedule+0xd8/0x1b4
schedule_timeout+0x474/0x560
wait_for_common+0x368/0x4e0
wait_for_completion+0x20/0x30
wait_for_completion+0x20/0x30
test_aead_vec_cfg+0xab4/0xd50
test_aead+0x144/0x1f0
alg_test_aead+0xd8/0x1e0
alg_test+0x634/0x890
cryptomgr_test+0x40/0x70
kthread+0x1e0/0x220
ret_from_fork+0x10/0x18
Kernel panic - not syncing: hung_task: blocked tasks
For padata_do_parallel, when the return err is 0 or -EBUSY, it will call
wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal
case, aead_request_complete() will be called in pcrypt_aead_serial and the
return err is 0 for padata_do_parallel. But, when pinst->flags is
PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it
won't call aead_request_complete(). Therefore, test_aead_vec_cfg will
hung at wait_for_completion(&wait->completion), which will cause
hungtask.
The problem comes as following:
(padata_do_parallel) |
rcu_read_lock_bh(); |
err = -EINVAL; | (padata_replace)
| pinst->flags |= PADATA_RESET;
err = -EBUSY |
if (pinst->flags & PADATA_RESET) |
rcu_read_unlock_bh() |
return err
In order to resolve the problem, we replace the return err -EBUSY with
-EAGAIN, which means parallel_data is changing, and the caller should call
it again.
v3:
remove retry and just change the return err.
v2:
introduce padata_try_do_parallel() in pcrypt_aead_encrypt and
pcrypt_aead_decrypt to solve the hungtask.
CVE-2023-52813
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
1. Navigate to the directory: /sys/kernel/debug/dri/0
2. Execute command: cat amdgpu_regs_smc
3. Exception Log::
[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000
[4005007.702562] #PF: supervisor instruction fetch in kernel mode
[4005007.702567] #PF: error_code(0x0010) - not-present page
[4005007.702570] PGD 0 P4D 0
[4005007.702576] Oops: 0010 [#1] SMP NOPTI
[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u
[4005007.702590] RIP: 0010:0x0
[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206
[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68
[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000
[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980
[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000
[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000
[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000
[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0
[4005007.702633] Call Trace:
[4005007.702636] <TASK>
[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]
[4005007.703002] full_proxy_read+0x5c/0x80
[4005007.703011] vfs_read+0x9f/0x1a0
[4005007.703019] ksys_read+0x67/0xe0
[4005007.703023] __x64_sys_read+0x19/0x20
[4005007.703028] do_syscall_64+0x5c/0xc0
[4005007.703034] ? do_user_addr_fault+0x1e3/0x670
[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0
[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20
[4005007.703052] ? irqentry_exit+0x19/0x30
[4005007.703057] ? exc_page_fault+0x89/0x160
[4005007.703062] ? asm_exc_page_fault+0x8/0x30
[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae
[4005007.703075] RIP: 0033:0x7f5e07672992
[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24
[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992
[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003
[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010
[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000
[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
[4005007.703105] </TASK>
[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca
[4005007.703184] CR2: 0000000000000000
[4005007.703188] ---[ en
---truncated---
CVE-2023-52817
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
For pptable structs that use flexible array sizes, use flexible arrays.
CVE-2023-52818
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
For pptable structs that use flexible array sizes, use flexible arrays.
CVE-2023-52819
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: fix a possible null pointer dereference
In versatile_panel_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2023-52821
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
We can get a UBSAN warning if ieee80211_get_tx_power() returns the
INT_MIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
-2147483648 * 100 cannot be represented in type 'int'
CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE
Call Trace:
dump_stack+0x74/0x92
ubsan_epilogue+0x9/0x50
handle_overflow+0x8d/0xd0
__ubsan_handle_mul_overflow+0xe/0x10
nl80211_send_iface+0x688/0x6b0 [cfg80211]
[...]
cfg80211_register_wdev+0x78/0xb0 [cfg80211]
cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
[...]
ieee80211_if_add+0x60e/0x8f0 [mac80211]
ieee80211_register_hw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate
that no data is available.
CVE-2023-52832
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atl1c: Work around the DMA RX overflow issue
This is based on alx driver commit 881d0327db37 ("net: alx: Work around
the DMA RX overflow issue").
The alx and atl1c drivers had RX overflow error which was why a custom
allocator was created to avoid certain addresses. The simpler workaround
then created for alx driver, but not for atl1c due to lack of tester.
Instead of using a custom allocator, check the allocated skb address and
use skb_reserve() to move away from problematic 0x...fc0 address.
Tested on AR8131 on Acer 4540.
CVE-2023-52834
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Bail out early if the request AUX area is out of bound
When perf-record with a large AUX area, e.g 4GB, it fails with:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)
and it reveals a WARNING with __alloc_pages():
------------[ cut here ]------------
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
Call trace:
__alloc_pages+0x1ec/0x248
__kmalloc_large_node+0xc0/0x1f8
__kmalloc_node+0x134/0x1e8
rb_alloc_aux+0xe0/0x298
perf_mmap+0x440/0x660
mmap_region+0x308/0x8a8
do_mmap+0x3c0/0x528
vm_mmap_pgoff+0xf4/0x1b8
ksys_mmap_pgoff+0x18c/0x218
__arm64_sys_mmap+0x38/0x58
invoke_syscall+0x50/0x128
el0_svc_common.constprop.0+0x58/0x188
do_el0_svc+0x34/0x50
el0_svc+0x34/0x108
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x1a4/0x1a8
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to
maintains AUX trace pages. The allocated page for this array is physically
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
WARNING.
So bail out early with -ENOMEM if the request AUX area is out of bound,
e.g.:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)
CVE-2023-52835
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
llc: verify mac len before reading mac header
LLC reads the mac header with eth_hdr without verifying that the skb
has an Ethernet header.
Syzbot was able to enter llc_rcv on a tun device. Tun can insert
packets without mac len and with user configurable skb->protocol
(passing a tun_pi header when not configuring IFF_NO_PI).
BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
There are further uses in include/net/llc_pdu.h. All these are
protected by a test skb->protocol == ETH_P_802_2. Which does not
protect against this tun scenario.
But the mac_len test added in this patch in llc_fixup_skb will
indirectly protect those too. That is called from llc_rcv before any
other LLC code.
It is tempting to just add a blanket mac_len check in llc_rcv, but
not sure whether that could break valid LLC paths that do not assume
an Ethernet header. 802.2 LLC may be used on top of non-802.3
protocols in principle. The below referenced commit shows that used
to, on top of Token Ring.
At least one of the three eth_hdr uses goes back to before the start
of git history. But the one that syzbot exercises is introduced in
this commit. That commit is old enough (2008), that effectively all
stable kernels should receive this.
CVE-2023-52843
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
syzbot reported the following uninit-value access issue [1]:
=====================================================
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
strlen lib/string.c:418 [inline]
strstr+0xb8/0x2f0 lib/string.c:756
tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
sock_sendmsg_nosec net/socket.c:730 [inline]
sock_sendmsg net/socket.c:753 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
__sys_sendmsg net/socket.c:2624 [inline]
__do_sys_sendmsg net/socket.c:2633 [inline]
__se_sys_sendmsg net/socket.c:2631 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at:
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
alloc_skb include/linux/skbuff.h:1286 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
sock_sendmsg_nosec net/socket.c:730 [inline]
sock_sendmsg net/socket.c:753 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
__sys_sendmsg net/socket.c:2624 [inline]
__do_sys_sendmsg net/socket.c:2633 [inline]
__se_sys_sendmsg net/socket.c:2631 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
TIPC bearer-related names including link names must be null-terminated
strings. If a link name which is not null-terminated is passed through
netlink, strstr() and similar functions can cause buffer overrun. This
causes the above issue.
This patch changes the nla_policy for bearer-related names from NLA_STRING
to NLA_NUL_STRING. This resolves the issue by ensuring that only
null-terminated strings are accepted as bearer-related names.
syzbot reported similar uninit-value issue related to bearer names [2]. The
root cause of this issue is that a non-null-terminated bearer name was
passed. This patch also resolved this issue.
CVE-2023-52845
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without
holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...
out:
spin_unlock_irqrestore(&hsotg->lock, flags);
When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
concurrently executed, the NULL check of "urb->hcpriv" can be executed
before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used
in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
pointer dereference.
This possible bug is found by an experimental static analysis tool
developed by myself. 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. The above possible
bug is reported, when my tool analyzes the source code of Linux 6.5.
To fix this possible bug, "urb->hcpriv = NULL" should be executed with
holding the lock "hsotg->lock". After using this patch, my tool never
reports the possible bug, with the kernelconfiguration allyesconfig for
x86_64. Because I have no associated hardware, I cannot test the patch
in runtime testing, and just verify it according to the code logic.
CVE-2023-52855
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: wmi: Fix opening of char device
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
file private data"), the miscdevice stores a pointer to itself inside
filp->private_data, which means that private_data will not be NULL when
wmi_char_open() is called. This might cause memory corruption should
wmi_char_open() be unable to find its driver, something which can
happen when the associated WMI device is deleted in wmi_free_devices().
Fix the problem by using the miscdevice pointer to retrieve the WMI
device data associated with a char device using container_of(). This
also avoids wmi_char_open() picking a wrong WMI device bound to a
driver with the same name as the original driver.
CVE-2023-52864
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2023-52865
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: possible buffer overflow
Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is
checked after access.
CVE-2023-52867
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
thermal: core: prevent potential string overflow
The dev->id value comes from ida_alloc() so it's a number between zero
and INT_MAX. If it's too high then these sprintf()s will overflow.
CVE-2023-52868
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2023-52875
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
If the "struct can_priv::echoo_skb" is accessed out of bounds, this
would cause a kernel crash. Instead, issue a meaningful warning
message and return with an error.
CVE-2023-52878
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires
CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.
CVE-2023-52880
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
tcp: do not accept ACK of bytes we never sent
This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.
ACK seq validation is currently following RFC 5961 5.2 guidelines:
The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded and an ACK sent back. It needs to
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
ACK, drop the segment, and return". The "ignored" above implies that
the processing of the incoming data segment continues, which means
the ACK value is treated as acceptable. This mitigation makes the
ACK check more stringent since any ACK < SND.UNA wouldn't be
accepted, instead only ACKs that are in the range ((SND.UNA -
MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.
This greatly improves TCP security at a little cost.
I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.
tp->bytes_acked was added in linux-4.2
Following packetdrill test (courtesy of Yepeng Pan) shows
the issue at hand:
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1024) = 0
// ---------------- Handshake ------------------- //
// when window scale is set to 14 the window size can be extended to
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
// ,though this ack number acknowledges some data never
// sent by the server.
+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14>
+0 > S. 0:0(0) ack 1 <...>
+0 < . 1:1(0) ack 1 win 65535
+0 accept(3, ..., ...) = 4
// For the established connection, we send an ACK packet,
// the ack packet uses ack number 1 - 1073725300 + 2^32,
// where 2^32 is used to wrap around.
// Note: we used 1073725300 instead of 1073725440 to avoid possible
// edge cases.
// 1 - 1073725300 + 2^32 = 3221241997
// Oops, old kernels happily accept this packet.
+0 < . 1:1001(1000) ack 3221241997 win 65535
// After the kernel fix the following will be replaced by a challenge ACK,
// and prior malicious frame would be dropped.
+0 > . 1:1(0) ack 1001
CVE-2023-52881
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix UAF in svc_tcp_listen_data_ready()
After the listener svc_sock is freed, and before invoking svc_tcp_accept()
for the established child sock, there is a window that the newsock
retaining a freed listener svc_sock in sk_user_data which cloning from
parent. In the race window, if data is received on the newsock, we will
observe use-after-free report in svc_tcp_listen_data_ready().
Reproduce by two tasks:
1. while :; do rpc.nfsd 0 ; rpc.nfsd; done
2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done
KASAN report:
==================================================================
BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]
Read of size 8 at addr ffff888139d96228 by task nc/102553
CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
<IRQ>
dump_stack_lvl+0x33/0x50
print_address_description.constprop.0+0x27/0x310
print_report+0x3e/0x70
kasan_report+0xae/0xe0
svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]
tcp_data_queue+0x9f4/0x20e0
tcp_rcv_established+0x666/0x1f60
tcp_v4_do_rcv+0x51c/0x850
tcp_v4_rcv+0x23fc/0x2e80
ip_protocol_deliver_rcu+0x62/0x300
ip_local_deliver_finish+0x267/0x350
ip_local_deliver+0x18b/0x2d0
ip_rcv+0x2fb/0x370
__netif_receive_skb_one_core+0x166/0x1b0
process_backlog+0x24c/0x5e0
__napi_poll+0xa2/0x500
net_rx_action+0x854/0xc90
__do_softirq+0x1bb/0x5de
do_softirq+0xcb/0x100
</IRQ>
<TASK>
...
</TASK>
Allocated by task 102371:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_kmalloc+0x7b/0x90
svc_setup_socket+0x52/0x4f0 [sunrpc]
svc_addsock+0x20d/0x400 [sunrpc]
__write_ports_addfd+0x209/0x390 [nfsd]
write_ports+0x239/0x2c0 [nfsd]
nfsctl_transaction_write+0xac/0x110 [nfsd]
vfs_write+0x1c3/0xae0
ksys_write+0xed/0x1c0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Freed by task 102551:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x50
__kasan_slab_free+0x106/0x190
__kmem_cache_free+0x133/0x270
svc_xprt_free+0x1e2/0x350 [sunrpc]
svc_xprt_destroy_all+0x25a/0x440 [sunrpc]
nfsd_put+0x125/0x240 [nfsd]
nfsd_svc+0x2cb/0x3c0 [nfsd]
write_threads+0x1ac/0x2a0 [nfsd]
nfsctl_transaction_write+0xac/0x110 [nfsd]
vfs_write+0x1c3/0xae0
ksys_write+0xed/0x1c0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready()
if state != TCP_LISTEN, that will avoid dereferencing svsk for all
child socket.
CVE-2023-52885
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
gsmi: fix null-deref in gsmi_get_variable
We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.
commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi.
CVE-2023-52893
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix null pointer dereference when host dies
Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
and cause null pointer dereference when host suddenly dies.
Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id]
virt device at the same time that xhci_kill_endpoint_urbs() tries to
loop through all the device's endpoints, checking if there are any
cancelled urbs left to give back.
hold the xhci spinlock while freeing the virt device
CVE-2023-52898
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Check endpoint is valid before dereferencing it
When the host controller is not responding, all URBs queued to all
endpoints need to be killed. This can cause a kernel panic if we
dereference an invalid endpoint.
Fix this by using xhci_get_virt_ep() helper to find the endpoint and
checking if the endpoint is valid before dereferencing it.
[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8
[233311.853964] pc : xhci_hc_died+0x10c/0x270
[233311.853971] lr : xhci_hc_died+0x1ac/0x270
[233311.854077] Call trace:
[233311.854085] xhci_hc_died+0x10c/0x270
[233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4
[233311.854105] call_timer_fn+0x50/0x2d4
[233311.854112] expire_timers+0xac/0x2e4
[233311.854118] run_timer_softirq+0x300/0xabc
[233311.854127] __do_softirq+0x148/0x528
[233311.854135] irq_exit+0x194/0x1a8
[233311.854143] __handle_domain_irq+0x164/0x1d0
[233311.854149] gic_handle_irq.22273+0x10c/0x188
[233311.854156] el1_irq+0xfc/0x1a8
[233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm]
[233311.854185] cpuidle_enter_state+0x1f0/0x764
[233311.854194] do_idle+0x594/0x6ac
[233311.854201] cpu_startup_entry+0x7c/0x80
[233311.854209] secondary_start_kernel+0x170/0x198
CVE-2023-52901
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in dummy_timer
Call Trace:
memcpy (mm/kasan/shadow.c:65)
dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
arch_static_branch (arch/x86/include/asm/jump_label.h:27)
static_key_false (include/linux/jump_label.h:207)
timer_expire_exit (include/trace/events/timer.h:127)
call_timer_fn (kernel/time/timer.c:1475)
expire_timers (kernel/time/timer.c:1519)
__run_timers (kernel/time/timer.c:1790)
run_timer_softirq (kernel/time/timer.c:1803)
CVE-2023-52907
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer
In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
CVE-2023-52915
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: pci: cx23885: check cx23885_vdev_init() return
cx23885_vdev_init() can return a NULL pointer, but that pointer
is used in the next line without a check.
Add a NULL pointer check and go to the error unwind if it is NULL.
CVE-2023-52918
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
netfilter: allow exp not to be removed in nf_ct_find_expectation
Currently nf_conntrack_in() calling nf_ct_find_expectation() will
remove the exp from the hash table. However, in some scenario, we
expect the exp not to be removed when the created ct will not be
confirmed, like in OVS and TC conntrack in the following patches.
This patch allows exp not to be removed by setting IPS_CONFIRMED
in the status of the tmpl.
CVE-2023-52927
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: fix handling and sanity checking of xattr_ids count
A Sysbot [1] corrupted filesystem exposes two flaws in the handling and
sanity checking of the xattr_ids count in the filesystem. Both of these
flaws cause computation overflow due to incorrect typing.
In the corrupted filesystem the xattr_ids value is 4294967071, which
stored in a signed variable becomes the negative number -225.
Flaw 1 (64-bit systems only):
The signed integer xattr_ids variable causes sign extension.
This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The
variable is first multiplied by sizeof(struct squashfs_xattr_id) where the
type of the sizeof operator is "unsigned long".
On a 64-bit system this is 64-bits in size, and causes the negative number
to be sign extended and widened to 64-bits and then become unsigned. This
produces the very large number 18446744073709548016 or 2^64 - 3600. This
number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and
divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0
(stored in len).
Flaw 2 (32-bit systems only):
On a 32-bit system the integer variable is not widened by the unsigned
long type of the sizeof operator (32-bits), and the signedness of the
variable has no effect due it always being treated as unsigned.
The above corrupted xattr_ids value of 4294967071, when multiplied
overflows and produces the number 4294963696 or 2^32 - 3400. This number
when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by
SQUASHFS_METADATA_SIZE overflows again and produces a length of 0.
The effect of the 0 length computation:
In conjunction with the corrupted xattr_ids field, the filesystem also has
a corrupted xattr_table_start value, where it matches the end of
filesystem value of 850.
This causes the following sanity check code to fail because the
incorrectly computed len of 0 matches the incorrect size of the table
reported by the superblock (0 bytes).
len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);
indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);
/*
* The computed size of the index table (len bytes) should exactly
* match the table start and end points
*/
start = table_start + sizeof(*id_table);
end = msblk->bytes_used;
if (len != (end - start))
return ERR_PTR(-EINVAL);
Changing the xattr_ids variable to be "usigned int" fixes the flaw on a
64-bit system. This relies on the fact the computation is widened by the
unsigned long type of the sizeof operator.
Casting the variable to u64 in the above macro fixes this flaw on a 32-bit
system.
It also means 64-bit systems do not implicitly rely on the type of the
sizeof operator to widen the computation.
[1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/
CVE-2023-52933
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: fix ->anon_vma race
If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires
it to be locked.
Page table traversal is allowed under any one of the mmap lock, the
anon_vma lock (if the VMA is associated with an anon_vma), and the
mapping lock (if the VMA is associated with a mapping); and so to be
able to remove page tables, we must hold all three of them.
retract_page_tables() bails out if an ->anon_vma is attached, but does
this check before holding the mmap lock (as the comment above the check
explains).
If we racily merged an existing ->anon_vma (shared with a child
process) from a neighboring VMA, subsequent rmap traversals on pages
belonging to the child will be able to see the page tables that we are
concurrently removing while assuming that nothing else can access them.
Repeat the ->anon_vma check once we hold the mmap lock to ensure that
there really is no concurrent page table access.
Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),
in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)".
It can also lead to use-after-free access.
CVE-2023-52935
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress
Bug report and analysis from Ding Hui.
During iSCSI session logout, if another task accesses the shost ipaddress
attr, we can get a KASAN UAF report like this:
[ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0
[ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088
[ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3
[ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 276.944470] Call Trace:
[ 276.944943] <TASK>
[ 276.945397] dump_stack_lvl+0x34/0x48
[ 276.945887] print_address_description.constprop.0+0x86/0x1e7
[ 276.946421] print_report+0x36/0x4f
[ 276.947358] kasan_report+0xad/0x130
[ 276.948234] kasan_check_range+0x35/0x1c0
[ 276.948674] _raw_spin_lock_bh+0x78/0xe0
[ 276.949989] iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]
[ 276.951765] show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]
[ 276.952185] dev_attr_show+0x3f/0x80
[ 276.953005] sysfs_kf_seq_show+0x1fb/0x3e0
[ 276.953401] seq_read_iter+0x402/0x1020
[ 276.954260] vfs_read+0x532/0x7b0
[ 276.955113] ksys_read+0xed/0x1c0
[ 276.955952] do_syscall_64+0x38/0x90
[ 276.956347] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 276.956769] RIP: 0033:0x7f5d3a679222
[ 276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[ 276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222
[ 276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003
[ 276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000
[ 276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000
[ 276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58
[ 276.960536] </TASK>
[ 276.961357] Allocated by task 2209:
[ 276.961756] kasan_save_stack+0x1e/0x40
[ 276.962170] kasan_set_track+0x21/0x30
[ 276.962557] __kasan_kmalloc+0x7e/0x90
[ 276.962923] __kmalloc+0x5b/0x140
[ 276.963308] iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]
[ 276.963712] iscsi_session_setup+0xda/0xba0 [libiscsi]
[ 276.964078] iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]
[ 276.964431] iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]
[ 276.964793] iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]
[ 276.965153] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[ 276.965546] netlink_unicast+0x4d5/0x7b0
[ 276.965905] netlink_sendmsg+0x78d/0xc30
[ 276.966236] sock_sendmsg+0xe5/0x120
[ 276.966576] ____sys_sendmsg+0x5fe/0x860
[ 276.966923] ___sys_sendmsg+0xe0/0x170
[ 276.967300] __sys_sendmsg+0xc8/0x170
[ 276.967666] do_syscall_64+0x38/0x90
[ 276.968028] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 276.968773] Freed by task 2209:
[ 276.969111] kasan_save_stack+0x1e/0x40
[ 276.969449] kasan_set_track+0x21/0x30
[ 276.969789] kasan_save_free_info+0x2a/0x50
[ 276.970146] __kasan_slab_free+0x106/0x190
[ 276.970470] __kmem_cache_free+0x133/0x270
[ 276.970816] device_release+0x98/0x210
[ 276.971145] kobject_cleanup+0x101/0x360
[ 276.971462] iscsi_session_teardown+0x3fb/0x530 [libiscsi]
[ 276.971775] iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]
[ 276.972143] iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]
[ 276.972485] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[ 276.972808] netlink_unicast+0x4d5/0x7b0
[ 276.973201] netlink_sendmsg+0x78d/0xc30
[ 276.973544] sock_sendmsg+0xe5/0x120
[ 276.973864] ____sys_sendmsg+0x5fe/0x860
[ 276.974248] ___sys_
---truncated---
CVE-2023-52975
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-52979
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()
snd_hda_get_connections() can return a negative error code.
It may lead to accessing 'conn' array at a negative index.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-52988
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region
This patch is fix for Linux kernel v2.6.33 or later.
For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem
have had an issue of use-after-free. The subsystem allows multiple
user space listeners to the region, while data of the payload was likely
released before the listeners execute read(2) to access to it for copying
to user space.
The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix
use-after-free regression in FCP handler"). The object of payload is
duplicated in kernel space for each listener. When the listener executes
ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to
be released.
However, it causes memory leak since the commit relies on call of
release_request() in drivers/firewire/core-cdev.c. Against the
expectation, the function is never called due to the design of
release_client_resource(). The function delegates release task
to caller when called with non-NULL fourth argument. The implementation
of ioctl_send_response() is the case. It should release the object
explicitly.
This commit fixes the bug.
CVE-2023-52989
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL
Baoquan reported that after triggering a crash the subsequent crash-kernel
fails to boot about half of the time. It triggers a NULL pointer
dereference in the periodic tick code.
This happens because the legacy timer interrupt (IRQ0) is resent in
software which happens in soft interrupt (tasklet) context. In this context
get_irq_regs() returns NULL which leads to the NULL pointer dereference.
The reason for the resend is a spurious APIC interrupt on the IRQ0 vector
which is captured and leads to a resend when the legacy timer interrupt is
enabled. This is wrong because the legacy PIC interrupts are level
triggered and therefore should never be resent in software, but nothing
ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not
know about their trigger type.
Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.
CVE-2023-52993
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()
if (!type)
continue;
if (type > RTAX_MAX)
return -EINVAL;
...
metrics[type - 1] = val;
@type being used as an array index, we need to prevent
cpu speculation or risk leaking kernel memory content.
CVE-2023-52997
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix oops due to uncleared server->smbd_conn in reconnect
In smbd_destroy(), clear the server->smbd_conn pointer after freeing the
smbd_connection struct that it points to so that reconnection doesn't get
confused.
CVE-2023-53006
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Make sure trace_printk() can output as soon as it can be used
Currently trace_printk() can be used as soon as early_trace_init() is
called from start_kernel(). But if a crash happens, and
"ftrace_dump_on_oops" is set on the kernel command line, all you get will
be:
[ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6
[ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6
[ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6
This is because the trace_printk() event (type 6) hasn't been registered
yet. That gets done via an early_initcall(), which may be early, but not
early enough.
Instead of registering the trace_printk() event (and other ftrace events,
which are not trace events) via an early_initcall(), have them registered at
the same time that trace_printk() can be used. This way, if there is a
crash before early_initcall(), then the trace_printk()s will actually be
useful.
CVE-2023-53007
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix potential memory leaks in session setup
Make sure to free cifs_ses::auth_key.response before allocating it as
we might end up leaking memory in reconnect or mounting.
CVE-2023-53008
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bnxt: Do not read past the end of test names
Test names were being concatenated based on a offset beyond the end of
the first name, which tripped the buffer overflow detection logic:
detected buffer overflow in strnlen
[...]
Call Trace:
bnxt_ethtool_init.cold+0x18/0x18
Refactor struct hwrm_selftest_qlist_output to use an actual array,
and adjust the concatenation to use snprintf() rather than a series of
strncat() calls.
CVE-2023-53010
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: betop: check shape of output reports
betopff_init() only checks the total sum of the report counts for each
report field to be at least 4, but hid_betopff_play() expects 4 report
fields.
A device advertising an output report with one field and 4 report counts
would pass the check but crash the kernel with a NULL pointer dereference
in hid_betopff_play().
CVE-2023-53015
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: validate parameter addr in mdiobus_get_phy()
The caller may pass any value as addr, what may result in an out-of-bounds
access to array mdio_map. One existing case is stmmac_init_phy() that
may pass -1 as addr. Therefore validate addr before using it.
CVE-2023-53019
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
l2tp: close all race conditions in l2tp_tunnel_register()
The code in l2tp_tunnel_register() is racy in several ways:
1. It modifies the tunnel socket _after_ publishing it.
2. It calls setup_udp_tunnel_sock() on an existing socket without
locking.
3. It changes sock lock class on fly, which triggers many syzbot
reports.
This patch amends all of them by moving socket initialization code
before publishing and under sock lock. As suggested by Jakub, the
l2tp lockdep class is not necessary as we can just switch to
bh_lock_sock_nested().
CVE-2023-53020
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: Fix use-after-free in local_cleanup()
Fix a use-after-free that occurs in kfree_skb() called from
local_cleanup(). This could happen when killing nfc daemon (e.g. neard)
after detaching an nfc device.
When detaching an nfc device, local_cleanup() called from
nfc_llcp_unregister_device() frees local->rx_pending and decreases
local->ref by kref_put() in nfc_llcp_local_put().
In the terminating process, nfc daemon releases all sockets and it leads
to decreasing local->ref. After the last release of local->ref,
local_cleanup() called from local_release() frees local->rx_pending
again, which leads to the bug.
Setting local->rx_pending to NULL in local_cleanup() could prevent
use-after-free when local_cleanup() is called twice.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in kfree_skb()
Call Trace:
dump_stack_lvl (lib/dump_stack.c:106)
print_address_description.constprop.0.cold (mm/kasan/report.c:306)
kasan_check_range (mm/kasan/generic.c:189)
kfree_skb (net/core/skbuff.c:955)
local_cleanup (net/nfc/llcp_core.c:159)
nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)
nfc_llcp_local_put (net/nfc/llcp_core.c:181)
llcp_sock_destruct (net/nfc/llcp_sock.c:959)
__sk_destruct (net/core/sock.c:2133)
sk_destruct (net/core/sock.c:2181)
__sk_free (net/core/sock.c:2192)
sk_free (net/core/sock.c:2203)
llcp_sock_release (net/nfc/llcp_sock.c:646)
__sock_release (net/socket.c:650)
sock_close (net/socket.c:1365)
__fput (fs/file_table.c:306)
task_work_run (kernel/task_work.c:179)
ptrace_notify (kernel/signal.c:2354)
syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)
syscall_exit_to_user_mode (kernel/entry/common.c:296)
do_syscall_64 (arch/x86/entry/common.c:86)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)
Allocated by task 4719:
kasan_save_stack (mm/kasan/common.c:45)
__kasan_slab_alloc (mm/kasan/common.c:325)
slab_post_alloc_hook (mm/slab.h:766)
kmem_cache_alloc_node (mm/slub.c:3497)
__alloc_skb (net/core/skbuff.c:552)
pn533_recv_response (drivers/nfc/pn533/usb.c:65)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)
usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)
tasklet_action_common.isra.0 (kernel/softirq.c:797)
__do_softirq (kernel/softirq.c:571)
Freed by task 1901:
kasan_save_stack (mm/kasan/common.c:45)
kasan_set_track (mm/kasan/common.c:52)
kasan_save_free_info (mm/kasan/genericdd.c:518)
__kasan_slab_free (mm/kasan/common.c:236)
kmem_cache_free (mm/slub.c:3809)
kfree_skbmem (net/core/skbuff.c:874)
kfree_skb (net/core/skbuff.c:931)
local_cleanup (net/nfc/llcp_core.c:159)
nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)
nfc_unregister_device (net/nfc/core.c:1179)
pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)
pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)
usb_unbind_interface (drivers/usb/core/driver.c:458)
device_release_driver_internal (drivers/base/dd.c:1279)
bus_remove_device (drivers/base/bus.c:529)
device_del (drivers/base/core.c:3665)
usb_disable_device (drivers/usb/core/message.c:1420)
usb_disconnect (drivers/usb/core.c:2261)
hub_event (drivers/usb/core/hub.c:5833)
process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)
worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)
kthread (kernel/kthread.c:319)
ret_from_fork (arch/x86/entry/entry_64.S:301)
CVE-2023-53023
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation
To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to
insufficient speculative store bypass mitigation") inserts lfence
instructions after 1) initializing a stack slot and 2) spilling a
pointer to the stack.
However, this does not cover cases where a stack slot is first
initialized with a pointer (subject to sanitization) but then
overwritten with a scalar (not subject to sanitization because
the slot was already initialized). In this case, the second write
may be subject to speculative store bypass (SSB) creating a
speculative pointer-as-scalar type confusion. This allows the
program to subsequently leak the numerical pointer value using,
for example, a branch-based cache side channel.
To fix this, also sanitize scalars if they write a stack slot
that previously contained a pointer. Assuming that pointer-spills
are only generated by LLVM on register-pressure, the performance
impact on most real-world BPF programs should be small.
The following unprivileged BPF bytecode drafts a minimal exploit
and the mitigation:
[...]
// r6 = 0 or 1 (skalar, unknown user input)
// r7 = accessible ptr for side channel
// r10 = frame pointer (fp), to be leaked
//
r9 = r10 # fp alias to encourage ssb
*(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked
// lfence added here because of pointer spill to stack.
//
// Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor
// for no r9-r10 dependency.
//
*(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr
// 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,
// store may be subject to SSB
//
// fix: also add an lfence when the slot contained a ptr
//
r8 = *(u64 *)(r9 - 8)
// r8 = architecturally a scalar, speculatively a ptr
//
// leak ptr using branch-based cache side channel:
r8 &= 1 // choose bit to leak
if r8 == 0 goto SLOW // no mispredict
// architecturally dead code if input r6 is 0,
// only executes speculatively iff ptr bit is 1
r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)
SLOW:
[...]
After running this, the program can time the access to *(r7 + 0) to
determine whether the chosen pointer bit was 0 or 1. Repeat this 64
times to recover the whole address on amd64.
In summary, sanitization can only be skipped if one scalar is
overwritten with another scalar. Scalar-confusion due to speculative
store bypass can not lead to invalid accesses because the pointer
bounds deducted during verification are enforced using branchless
logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on
pointer arithmetic") for details.
Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks}
because speculative leaks are likely unexpected if these were enabled.
For example, leaking the address to a protected log file may be acceptable
while disabling the mitigation might unintentionally leak the address
into the cached-state of a map that is accessible to unprivileged
processes.
CVE-2023-53024
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP
and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.
Command to trigger the warning:
# perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5
Performance counter stats for 'sleep 5':
0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/
5.002117947 seconds time elapsed
0.000131000 seconds user
0.001063000 seconds sys
Below is snippet of the warning in dmesg:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec
preempt_count: 2, expected: 0
4 locks held by perf-exec/2869:
#0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90
#1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0
#2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510
#3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510
irq event stamp: 4806
hardirqs last enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0
hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510
softirqs last enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0
softirqs last disabled at (0): [<0000000000000000>] 0x0
CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61
Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
Call Trace:
dump_stack_lvl+0x98/0xe0 (unreliable)
__might_resched+0x2f8/0x310
__mutex_lock+0x6c/0x13f0
thread_imc_event_add+0xf4/0x1b0
event_sched_in+0xe0/0x210
merge_sched_in+0x1f0/0x600
visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0
ctx_flexible_sched_in+0xcc/0x140
ctx_sched_in+0x20c/0x2a0
ctx_resched+0x104/0x1c0
perf_event_exec+0x340/0x510
begin_new_exec+0x730/0xef0
load_elf_binary+0x3f8/0x1e10
...
do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0
WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0
CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61
Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670
REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2)
MSR: 9000000000021033 <SF,HV,ME,IR,DR,RI,LE> CR: 48002824 XER: 00000000
CFAR: c00000000013fb64 IRQMASK: 1
The above warning triggered because the current imc-pmu code uses mutex
lock in interrupt disabled sections. The function mutex_lock()
internally calls __might_resched(), which will check if IRQs are
disabled and in case IRQs are disabled, it will trigger the warning.
Fix the issue by changing the mutex lock to spinlock.
[mpe: Fix comments, trim oops in change log, add reported-by tags]
CVE-2023-53031
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.
When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of
an arithmetic expression 2 << (netmask - mask_bits - 1) is subject
to overflow due to a failure casting operands to a larger data type
before performing the arithmetic.
Note that it's harmless since the value will be checked at the next step.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.
CVE-2023-53032
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: intel-ish-hid: ipc: Fix potential use-after-free in work function
When a reset notify IPC message is received, the ISR schedules a work
function and passes the ISHTP device to it via a global pointer
ishtp_dev. If ish_probe() fails, the devm-managed device resources
including ishtp_dev are freed, but the work is not cancelled, causing a
use-after-free when the work function tries to access ishtp_dev. Use
devm_work_autocancel() instead, so that the work is automatically
cancelled if probe fails.
CVE-2023-53039
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Perform lockless command completion in abort path
While adding and removing the controller, the following call trace was
observed:
WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50
CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1
RIP: 0010:dma_free_attrs+0x33/0x50
Call Trace:
qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx]
qla2x00_abort_srb+0x8e/0x250 [qla2xxx]
? ql_dbg+0x70/0x100 [qla2xxx]
__qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx]
qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx]
qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx]
qla2x00_remove_one+0x364/0x400 [qla2xxx]
pci_device_remove+0x36/0xa0
__device_release_driver+0x17a/0x230
device_release_driver+0x24/0x30
pci_stop_bus_device+0x68/0x90
pci_stop_and_remove_bus_device_locked+0x16/0x30
remove_store+0x75/0x90
kernfs_fop_write_iter+0x11c/0x1b0
new_sync_write+0x11f/0x1b0
vfs_write+0x1eb/0x280
ksys_write+0x5f/0xe0
do_syscall_64+0x5c/0x80
? do_user_addr_fault+0x1d8/0x680
? do_syscall_64+0x69/0x80
? exc_page_fault+0x62/0x140
? asm_exc_page_fault+0x8/0x30
entry_SYSCALL_64_after_hwframe+0x44/0xae
The command was completed in the abort path during driver unload with a
lock held, causing the warning in abort path. Hence complete the command
without any lock held.
CVE-2023-53041
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm stats: check for and propagate alloc_percpu failure
Check alloc_precpu()'s return value and return an error from
dm_stats_init() if it fails. Update alloc_dev() to fail if
dm_stats_init() does.
Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup()
even if dm-stats isn't being actively used.
CVE-2023-53044
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_audio: don't let userspace block driver unbind
In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free()
via g_audio_cleanup() will disconnect the card and then wait for all
resources to be released, which happens when the refcount falls to zero.
Since userspace can keep the refcount incremented by not closing the
relevant file descriptor, the call to unbind may block indefinitely.
This can cause a deadlock during reboot, as evidenced by the following
blocked task observed on my machine:
task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c
Call trace:
__switch_to+0xc8/0x140
__schedule+0x2f0/0x7c0
schedule+0x60/0xd0
schedule_timeout+0x180/0x1d4
wait_for_completion+0x78/0x180
snd_card_free+0x90/0xa0
g_audio_cleanup+0x2c/0x64
afunc_unbind+0x28/0x60
...
kernel_restart+0x4c/0xac
__do_sys_reboot+0xcc/0x1ec
__arm64_sys_reboot+0x28/0x30
invoke_syscall+0x4c/0x110
...
The issue can also be observed by opening the card with arecord and
then stopping the process through the shell before unbinding:
# arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null
Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null
# echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind
(observe that the unbind command never finishes)
Fix the problem by using snd_card_free_when_closed() instead, which will
still disconnect the card as desired, but defer the task of freeing the
resources to the core once userspace closes its file descriptor.
CVE-2023-53045
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm crypt: add cond_resched() to dmcrypt_write()
The loop in dmcrypt_write may be running for unbounded amount of time,
thus we need cond_resched() in it.
This commit fixes the following warning:
[ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897]
...
[ 3391.387210][ C12] Call trace:
[ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158
[ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0
[ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550
[ 3391.405856][ C12] submit_bio_noacct+0x308/0x380
[ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt]
[ 3391.416005][ C12] kthread+0x130/0x138
[ 3391.419911][ C12] ret_from_fork+0x10/0x18
CVE-2023-53051
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Synchronize the IOCB count to be in order
A system hang was observed with the following call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1
Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022
RIP: 0010:__wake_up_common+0x55/0x190
Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d
40 e8 48 8d 43 08 48 89 04 24 48 89 c6\
49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31
ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d
RSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082
RAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018
RBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8
R10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0
Call Trace:
<TASK>
__wake_up_common_lock+0x83/0xd0
qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx]
__nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc]
nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc]
nvme_fc_delete_association+0x1bf/0x220 [nvme_fc]
? nvme_remove_namespaces+0x9f/0x140 [nvme_core]
nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core]
nvme_sysfs_delete+0x5f/0x70 [nvme_core]
kernfs_fop_write_iter+0x12b/0x1c0
vfs_write+0x2a3/0x3b0
ksys_write+0x5f/0xe0
do_syscall_64+0x5c/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
? exit_to_user_mode_loop+0xd0/0x130
? exit_to_user_mode_prepare+0xec/0x100
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f815cd3eb97
The IOCB counts are out of order and that would block any commands from
going out and subsequently hang the system. Synchronize the IOCB count to
be in correct order.
CVE-2023-53056
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igb: revert rtnl_lock() that causes deadlock
The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds
rtnl_lock to eliminate a false data race shown below
(FREE from device detaching) | (USE from netdev core)
igb_remove | igb_ndo_get_vf_config
igb_disable_sriov | vf >= adapter->vfs_allocated_count?
kfree(adapter->vf_data) |
adapter->vfs_allocated_count = 0 |
| memcpy(... adapter->vf_data[vf]
The above race will never happen and the extra rtnl_lock causes deadlock
below
[ 141.420169] <TASK>
[ 141.420672] __schedule+0x2dd/0x840
[ 141.421427] schedule+0x50/0xc0
[ 141.422041] schedule_preempt_disabled+0x11/0x20
[ 141.422678] __mutex_lock.isra.13+0x431/0x6b0
[ 141.423324] unregister_netdev+0xe/0x20
[ 141.423578] igbvf_remove+0x45/0xe0 [igbvf]
[ 141.423791] pci_device_remove+0x36/0xb0
[ 141.423990] device_release_driver_internal+0xc1/0x160
[ 141.424270] pci_stop_bus_device+0x6d/0x90
[ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20
[ 141.424789] pci_iov_remove_virtfn+0xba/0x120
[ 141.425452] sriov_disable+0x2f/0xf0
[ 141.425679] igb_disable_sriov+0x4e/0x100 [igb]
[ 141.426353] igb_remove+0xa0/0x130 [igb]
[ 141.426599] pci_device_remove+0x36/0xb0
[ 141.426796] device_release_driver_internal+0xc1/0x160
[ 141.427060] driver_detach+0x44/0x90
[ 141.427253] bus_remove_driver+0x55/0xe0
[ 141.427477] pci_unregister_driver+0x2a/0xa0
[ 141.428296] __x64_sys_delete_module+0x141/0x2b0
[ 141.429126] ? mntput_no_expire+0x4a/0x240
[ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0
[ 141.429653] do_syscall_64+0x5b/0x80
[ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0
[ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30
[ 141.430849] ? do_syscall_64+0x67/0x80
[ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0
[ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30
[ 141.432482] ? do_syscall_64+0x67/0x80
[ 141.432714] ? exc_page_fault+0x64/0x140
[ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Since the igb_disable_sriov() will call pci_disable_sriov() before
releasing any resources, the netdev core will synchronize the cleanup to
avoid any races. This patch removes the useless rtnl_(un)lock to guarantee
correctness.
CVE-2023-53060
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc95xx: Limit packet length to skb->len
Packet length retrieved from descriptor may be larger than
the actual socket buffer length. In such case the cloned
skb passed up the network stack will leak kernel memory contents.
CVE-2023-53062
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-53063
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info
We have to make sure that the info returned by the helper is valid
before using it.
Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.
CVE-2023-53066
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: lan78xx: Limit packet length to skb->len
Packet length retrieved from descriptor may be larger than
the actual socket buffer length. In such case the cloned
skb passed up the network stack will leak kernel memory contents.
Additionally prevent integer underflow when size is less than
ETH_FCS_LEN.
CVE-2023-53068
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix invalid address access in lookup_rec() when index is 0
KASAN reported follow problem:
BUG: KASAN: use-after-free in lookup_rec
Read of size 8 at addr ffff000199270ff0 by task modprobe
CPU: 2 Comm: modprobe
Call trace:
kasan_report
__asan_load8
lookup_rec
ftrace_location
arch_check_ftrace_location
check_kprobe_address_safe
register_kprobe
When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a
pg which is newly added to ftrace_pages_start in ftrace_process_locs().
Before the first pg->index++, index is 0 and accessing pg->records[-1].ip
will cause this problem.
Don't check the ip when pg->index is 0.
CVE-2023-53075
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
freed, which will cause following memleak:
unreferenced object 0xffff88810b2c6980 (size 32):
comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............
backtrace:
[<0000000098f3a26d>] alua_activate+0xb0/0x320
[<000000003b529641>] scsi_dh_activate+0xb2/0x140
[<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]
[<000000007adc9ace>] process_one_work+0x3c5/0x730
[<00000000c457a985>] worker_thread+0x93/0x650
[<00000000cb80e628>] kthread+0x1ba/0x210
[<00000000a1e61077>] ret_from_fork+0x22/0x30
Fix the problem by freeing 'qdata' in error path.
CVE-2023-53078
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix steering rules cleanup
vport's mc, uc and multicast rules are not deleted in teardown path when
EEH happens. Since the vport's promisc settings(uc, mc and all) in
firmware are reset after EEH, mlx5 driver will try to delete the above
rules in the initialization path. This cause kernel crash because these
software rules are no longer valid.
Fix by nullifying these rules right after delete to avoid accessing any dangling
pointers.
Call Trace:
__list_del_entry_valid+0xcc/0x100 (unreliable)
tree_put_node+0xf4/0x1b0 [mlx5_core]
tree_remove_node+0x30/0x70 [mlx5_core]
mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core]
esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core]
esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core]
esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core]
esw_enable_vport+0x130/0x260 [mlx5_core]
mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core]
mlx5_device_enable_sriov+0x74/0x440 [mlx5_core]
mlx5_load_one+0x114c/0x1550 [mlx5_core]
mlx5_pci_resume+0x68/0xf0 [mlx5_core]
eeh_report_resume+0x1a4/0x230
eeh_pe_dev_traverse+0x98/0x170
eeh_handle_normal_event+0x3e4/0x640
eeh_handle_event+0x4c/0x370
eeh_event_handler+0x14c/0x210
kthread+0x168/0x1b0
ret_from_kernel_thread+0x5c/0x84
CVE-2023-53079
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xsk: Add missing overflow check in xdp_umem_reg
The number of chunks can overflow u32. Make sure to return -EINVAL on
overflow. Also remove a redundant u32 cast assigning umem->npgs.
CVE-2023-53080
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after failed write
When buffered write fails to copy data into underlying page cache page,
ocfs2_write_end_nolock() just zeroes out and dirties the page. This can
leave dirty page beyond EOF and if page writeback tries to write this page
before write succeeds and expands i_size, page gets into inconsistent
state where page dirty bit is clear but buffer dirty bits stay set
resulting in page data never getting written and so data copied to the
page is lost. Fix the problem by invalidating page beyond EOF after
failed write.
CVE-2023-53081
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix an illegal memory access
In the kfd_wait_on_events() function, the kfd_event_waiter structure is
allocated by alloc_event_waiters(), but the event field of the waiter
structure is not initialized; When copy_from_user() fails in the
kfd_wait_on_events() function, it will enter exception handling to
release the previously allocated memory of the waiter structure;
Due to the event field of the waiters structure being accessed
in the free_waiters() function, this results in illegal memory access
and system crash, here is the crash log:
localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0
localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082
localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000
localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0
localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64
localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002
localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698
localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000
localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0
localhost kernel: Call Trace:
localhost kernel: _raw_spin_lock_irqsave+0x30/0x40
localhost kernel: remove_wait_queue+0x12/0x50
localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu]
localhost kernel: ? ftrace_graph_caller+0xa0/0xa0
localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu]
localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu]
localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu]
localhost kernel: ? ftrace_graph_caller+0xa0/0xa0
localhost kernel: __x64_sys_ioctl+0x8e/0xd0
localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0
localhost kernel: do_syscall_64+0x33/0x80
localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
localhost kernel: RIP: 0033:0x152a4dff68d7
Allocate the structure with kcalloc, and remove redundant 0-initialization
and a redundant loop condition check.
CVE-2023-53090
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal
replay, which is obviously unreasonable because we have successfully loaded
and replayed the journal through the old s_journal_inum. And the new
s_journal_inum bypasses some of the checks in ext4_get_journal(), which
may trigger a null pointer dereference problem. So if s_journal_inum
changes after the journal replay, we ignore the change, and rewrite the
current journal_inum to the superblock.
CVE-2023-53091
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: fix race on RX DMA shutdown
From time to time DMA completion can come in the middle of DMA shutdown:
<process ctx>: <IRQ>:
lpuart32_shutdown()
lpuart_dma_shutdown()
del_timer_sync()
lpuart_dma_rx_complete()
lpuart_copy_rx_to_tty()
mod_timer()
lpuart_dma_rx_free()
When the timer fires a bit later, sport->dma_rx_desc is NULL:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
pc : lpuart_copy_rx_to_tty+0xcc/0x5bc
lr : lpuart_timer_func+0x1c/0x2c
Call trace:
lpuart_copy_rx_to_tty
lpuart_timer_func
call_timer_fn
__run_timers.part.0
run_timer_softirq
__do_softirq
__irq_exit_rcu
irq_exit
handle_domain_irq
gic_handle_irq
call_on_irq_stack
do_interrupt_handler
...
To fix this fold del_timer_sync() into lpuart_dma_rx_free() after
dmaengine_terminate_sync() to make sure timer will not be re-started in
lpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete().
CVE-2023-53094
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in ext4_update_inline_data
Syzbot found the following issue:
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
Modules linked in:
CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__alloc_pages_node include/linux/gfp.h:237 [inline]
alloc_pages_node include/linux/gfp.h:260 [inline]
__kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113
__do_kmalloc_node mm/slab_common.c:956 [inline]
__kmalloc+0xfe/0x190 mm/slab_common.c:981
kmalloc include/linux/slab.h:584 [inline]
kzalloc include/linux/slab.h:720 [inline]
ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346
ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]
ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307
ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385
ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772
ext4_create+0x36c/0x560 fs/ext4/namei.c:2817
lookup_open fs/namei.c:3413 [inline]
open_last_lookups fs/namei.c:3481 [inline]
path_openat+0x12ac/0x2dd0 fs/namei.c:3711
do_filp_open+0x264/0x4f0 fs/namei.c:3741
do_sys_openat2+0x124/0x4e0 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_openat fs/open.c:1342 [inline]
__se_sys_openat fs/open.c:1337 [inline]
__x64_sys_openat+0x243/0x290 fs/open.c:1337
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Above issue happens as follows:
ext4_iget
ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60
ext4_try_add_inline_entry
__ext4_mark_inode_dirty
ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44
ext4_xattr_shift_entries
->after shift i_inline_off is incorrect, actually is change to 176
ext4_try_add_inline_entry
ext4_update_inline_dir
get_max_inline_xattr_value_size
if (EXT4_I(inode)->i_inline_off)
entry = (struct ext4_xattr_entry *)((void *)raw_inode +
EXT4_I(inode)->i_inline_off);
free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));
->As entry is incorrect, then 'free' may be negative
ext4_update_inline_data
value = kzalloc(len, GFP_NOFS);
-> len is unsigned int, maybe very large, then trigger warning when
'kzalloc()'
To resolve the above issue we need to update 'i_inline_off' after
'ext4_xattr_shift_entries()'. We do not need to set
EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()
already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA
when it is needed may trigger a BUG_ON in ext4_writepages().
CVE-2023-53100
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: zero i_disksize when initializing the bootloader inode
If the boot loader inode has never been used before, the
EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
i_size to 0. However, if the "never before used" boot loader has a
non-zero i_size, then i_disksize will be non-zero, and the
inconsistency between i_size and i_disksize can trigger a kernel
warning:
WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
Call Trace:
vfs_write+0x3b1/0x5c0
ksys_write+0x77/0x160
__x64_sys_write+0x22/0x30
do_syscall_64+0x39/0x80
Reproducer:
1. create corrupted image and mount it:
mke2fs -t ext4 /tmp/foo.img 200
debugfs -wR "sif <5> size 25700" /tmp/foo.img
mount -t ext4 /tmp/foo.img /mnt
cd /mnt
echo 123 > file
2. Run the reproducer program:
posix_memalign(&buf, 1024, 1024)
fd = open("file", O_RDWR | O_DIRECT);
ioctl(fd, EXT4_IOC_SWAP_BOOT);
write(fd, buf, 1024);
Fix this by setting i_disksize as well as i_size to zero when
initiaizing the boot loader inode.
CVE-2023-53101
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails
syzbot reported a warning[1] where the bond device itself is a slave and
we try to enslave a non-ethernet device as the first slave which fails
but then in the error path when ether_setup() restores the bond device
it also clears all flags. In my previous fix[2] I restored the
IFF_MASTER flag, but I didn't consider the case that the bond device
itself might also be a slave with IFF_SLAVE set, so we need to restore
that flag as well. Use the bond_ether_setup helper which does the right
thing and restores the bond's flags properly.
Steps to reproduce using a nlmon dev:
$ ip l add nlmon0 type nlmon
$ ip l add bond1 type bond
$ ip l add bond2 type bond
$ ip l set bond1 master bond2
$ ip l set dev nlmon0 master bond1
$ ip -d l sh dev bond1
22: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000
(now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we
try to delete it)
[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef
[2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")
[3] example warning:
[ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address
[ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address
[ 32.464639] bond1 (unregistering): Released all slaves
[ 32.464685] ------------[ cut here ]------------
[ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780
[ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net
[ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47
[ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
[ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780
[ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59
[ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206
[ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000
[ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520
[ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728
[ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140
[ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140
[ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000
[ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0
[ 32.464730] Call Trace:
[ 32.464763] <TASK>
[ 32.464767] rtnl_dellink+0x13e/0x380
[ 32.464776] ? cred_has_capability.isra.0+0x68/0x100
[ 32.464780] ? __rtnl_unlock+0x33/0x60
[ 32.464783] ? bpf_lsm_capset+0x10/0x10
[ 32.464786] ? security_capable+0x36/0x50
[ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0
[ 32.464792] ? _copy_to_iter+0xb1/0x790
[ 32.464796] ? post_alloc_hook+0xa0/0x160
[ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110
[ 32.464802] netlink_rcv_skb+0x50/0xf0
[ 32.464806] netlink_unicast+0x216/0x340
[ 32.464809] netlink_sendmsg+0x23f/0x480
[ 32.464812] sock_sendmsg+0x5e/0x60
[ 32.464815] ____sys_sendmsg+0x22c/0x270
[ 32.464818] ? import_iovec+0x17/0x20
[ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90
[ 32.464823] ? do_set_pte+0xa0/0xe0
[ 32.464828] ___sys_sendmsg+0x81/0xc0
[ 32.464832] ? mod_objcg_state+0xc6/0x300
[ 32.464835] ? refill_obj_stock+0xa9/0x160
[ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0
[ 32.464842] __sys_sendm
---truncated---
CVE-2023-53103
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: Fix size of interrupt data
iucv_irq_data needs to be 4 bytes larger.
These bytes are not used by the iucv module, but written by
the z/VM hypervisor in case a CPU is deconfigured.
Reported as:
BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten
-----------------------------------------------------------------------------
0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc
Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1
__kmem_cache_alloc_node+0x166/0x450
kmalloc_node_trace+0x3a/0x70
iucv_cpu_prepare+0x44/0xd0
cpuhp_invoke_callback+0x156/0x2f0
cpuhp_issue_call+0xf0/0x298
__cpuhp_setup_state_cpuslocked+0x136/0x338
__cpuhp_setup_state+0xf4/0x288
iucv_init+0xf4/0x280
do_one_initcall+0x78/0x390
do_initcalls+0x11a/0x140
kernel_init_freeable+0x25e/0x2a0
kernel_init+0x2e/0x170
__ret_from_fork+0x3c/0x58
ret_from_fork+0xa/0x40
Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1
__kmem_cache_free+0x308/0x358
iucv_init+0x92/0x280
do_one_initcall+0x78/0x390
do_initcalls+0x11a/0x140
kernel_init_freeable+0x25e/0x2a0
kernel_init+0x2e/0x170
__ret_from_fork+0x3c/0x58
ret_from_fork+0xa/0x40
Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0|
Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000
Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................
Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................
Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................
Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................
Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................
Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................
Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................
Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........
Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Padding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Padding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1
Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)
Call Trace:
[<000000032aa034ec>] dump_stack_lvl+0xac/0x100
[<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140
[<0000000329f5aa78>] check_object+0x370/0x3c0
[<0000000329f5ede6>] free_debug_processing+0x15e/0x348
[<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0
[<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8
[<0000000329f61768>] __kmem_cache_free+0x308/0x358
[<000000032a91465c>] iucv_cpu_dead+0x6c/0x88
[<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0
[<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0
[<0000000329c3243e>] cpu_device_down+0x4e/0x78
[<000000032a61dee0>] device_offline+0xc8/0x118
[<000000032a61e048>] online_store+0x60/0xe0
[<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8
[<0000000329fab65c>] vfs_write+0x174/0x360
[<0000000329fab9fc>] ksys_write+0x74/0x100
[<000000032aa03a5a>] __do_syscall+0x1da/0x208
[<000000032aa177b2>] system_call+0x82/0xb0
INFO: lockdep is turned off.
FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc
FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed
CVE-2023-53108
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix kernel crash during reboot when adapter is in recovery mode
If the driver detects during probe that firmware is in recovery
mode then i40e_init_recovery_mode() is called and the rest of
probe function is skipped including pci_set_drvdata(). Subsequent
i40e_shutdown() called during shutdown/reboot dereferences NULL
pointer as pci_get_drvdata() returns NULL.
To fix call pci_set_drvdata() also during entering to recovery mode.
Reproducer:
1) Lets have i40e NIC with firmware in recovery mode
2) Run reboot
Result:
[ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver
[ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.
[ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.
[ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0
[ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.
[ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0
...
[ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2
[ 156.318330] #PF: supervisor write access in kernel mode
[ 156.323546] #PF: error_code(0x0002) - not-present page
[ 156.328679] PGD 0 P4D 0
[ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1
[ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022
[ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]
[ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 <f0> 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00
[ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282
[ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001
[ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000
[ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40
[ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000
[ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000
[ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000
[ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0
[ 156.438944] PKRU: 55555554
[ 156.441647] Call Trace:
[ 156.444096] <TASK>
[ 156.446199] pci_device_shutdown+0x38/0x60
[ 156.450297] device_shutdown+0x163/0x210
[ 156.454215] kernel_restart+0x12/0x70
[ 156.457872] __do_sys_reboot+0x1ab/0x230
[ 156.461789] ? vfs_writev+0xa6/0x1a0
[ 156.465362] ? __pfx_file_free_rcu+0x10/0x10
[ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0
[ 156.475034] do_syscall_64+0x3e/0x90
[ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 156.483658] RIP: 0033:0x7fe7bff37ab7
CVE-2023-53114
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: prevent out-of-bounds array speculation when closing a file descriptor
Google-Bug-Id: 114199369
CVE-2023-53117
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix a procfs host directory removal regression
scsi_proc_hostdir_rm() decreases a reference counter and hence must only be
called once per host that is removed. This change does not require a
scsi_add_host_with_dma() change since scsi_add_host_with_dma() will return
0 (success) if scsi_proc_host_add() is called.
CVE-2023-53118
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_make_synack() can be called from process context
tcp_rtx_synack() now could be called in process context as explained in
0a375c822497 ("tcp: tcp_rtx_synack() can be called from process
context").
tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU
variables with preemption enabled. This causes the following BUG:
BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464
caller is tcp_make_synack+0x841/0xac0
Call Trace:
<TASK>
dump_stack_lvl+0x10d/0x1a0
check_preemption_disabled+0x104/0x110
tcp_make_synack+0x841/0xac0
tcp_v6_send_synack+0x5c/0x450
tcp_rtx_synack+0xeb/0x1f0
inet_rtx_syn_ack+0x34/0x60
tcp_check_req+0x3af/0x9e0
tcp_rcv_state_process+0x59b/0x2030
tcp_v6_do_rcv+0x5f5/0x700
release_sock+0x3a/0xf0
tcp_sendmsg+0x33/0x40
____sys_sendmsg+0x2f2/0x490
__sys_sendmsg+0x184/0x230
do_syscall_64+0x3d/0x90
Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. Use
TCP_INC_STATS() which is safe to be called from context switch.
CVE-2023-53121
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add()
Port is allocated by sas_port_alloc_num() and rphy is allocated by either
sas_end_device_alloc() or sas_expander_alloc(), all of which may return
NULL. So we need to check the rphy to avoid possible NULL pointer access.
If sas_rphy_add() returned with failure, rphy is set to NULL. We would
access the rphy in the following lines which would also result NULL pointer
access.
CVE-2023-53124
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc75xx: Limit packet length to skb->len
Packet length retrieved from skb data may be larger than
the actual socket buffer length (up to 9026 bytes). In such
case the cloned skb passed up the network stack will leak
kernel memory contents.
CVE-2023-53125
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a server shutdown leak
Fix a race where kthread_stop() may prevent the threadfn from ever getting
called. If that happens the svc_rqst will not be cleaned up.
CVE-2023-53131
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()
When the buffer length of the recvmsg system call is 0, we got the
flollowing soft lockup problem:
watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]
CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:remove_wait_queue+0xb/0xc0
Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20
RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768
RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040
RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7
R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800
R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0
FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tcp_msg_wait_data+0x279/0x2f0
tcp_bpf_recvmsg_parser+0x3c6/0x490
inet_recvmsg+0x280/0x290
sock_recvmsg+0xfc/0x120
____sys_recvmsg+0x160/0x3d0
___sys_recvmsg+0xf0/0x180
__sys_recvmsg+0xea/0x1a0
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
The logic in tcp_bpf_recvmsg_parser is as follows:
msg_bytes_ready:
copied = sk_msg_recvmsg(sk, psock, msg, len, flags);
if (!copied) {
wait data;
goto msg_bytes_ready;
}
In this case, "copied" always is 0, the infinite loop occurs.
According to the Linux system call man page, 0 should be returned in this
case. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directly
return. Also modify several other functions with the same problem.
CVE-2023-53133
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties
devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause
out-of-bounds write in device_property_read_u8_array later.
CVE-2023-53139
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Remove the /proc/scsi/${proc_name} directory earlier
Remove the /proc/scsi/${proc_name} directory earlier to fix a race
condition between unloading and reloading kernel modules. This fixes a bug
introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in
the SCSI core").
Fix the following kernel warning:
proc_dir_entry 'scsi/scsi_debug' already registered
WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0
Call Trace:
proc_mkdir+0xb5/0xe0
scsi_proc_hostdir_add+0xb5/0x170
scsi_host_alloc+0x683/0x6c0
sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]
really_probe+0x159/0x540
__driver_probe_device+0xdc/0x230
driver_probe_device+0x4f/0x120
__device_attach_driver+0xef/0x180
bus_for_each_drv+0xe5/0x130
__device_attach+0x127/0x290
device_initial_probe+0x17/0x20
bus_probe_device+0x110/0x130
device_add+0x673/0xc80
device_register+0x1e/0x30
sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]
scsi_debug_init+0x64f/0x1000 [scsi_debug]
do_one_initcall+0xd7/0x470
do_init_module+0xe7/0x330
load_module+0x122a/0x12c0
__do_sys_finit_module+0x124/0x1a0
__x64_sys_finit_module+0x46/0x50
do_syscall_64+0x38/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2023-53140
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
ila_xlat_nl_cmd_get_mapping() generates an empty skb,
triggerring a recent sanity check [1].
Instead, return an error code, so that user space
can get it.
[1]
skb_assert_len
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
Modules linked in:
CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_assert_len include/linux/skbuff.h:2527 [inline]
pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
lr : skb_assert_len include/linux/skbuff.h:2527 [inline]
lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
sp : ffff80001e0d6c40
x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0
x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00
x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10
x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0
x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600
x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e
Call trace:
skb_assert_len include/linux/skbuff.h:2527 [inline]
__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
dev_queue_xmit include/linux/netdevice.h:3033 [inline]
__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]
__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325
netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338
__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]
netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292
netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380
nlmsg_unicast include/net/netlink.h:1099 [inline]
genlmsg_unicast include/net/genetlink.h:433 [inline]
genlmsg_reply include/net/genetlink.h:443 [inline]
ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493
genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065
netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574
genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x558/0x844 net/socket.c:2479
___sys_sendmsg net/socket.c:2533 [inline]
__sys_sendmsg+0x26c/0x33c net/socket.c:2562
__do_sys_sendmsg net/socket.c:2571 [inline]
__se_sys_sendmsg net/socket.c:2569 [inline]
__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193
el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
irq event stamp: 136484
hardirqs last enabled at (136483): [<ffff800008350244>] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345
hardirqs last disabled at (136484): [<ffff800012358d60>] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405
softirqs last enabled at (136418): [<ffff800008020ea8>] softirq_ha
---truncated---
CVE-2023-53141
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
igb: Fix igb_down hung on surprise removal
In a setup where a Thunderbolt hub connects to Ethernet and a display
through USB Type-C, users may experience a hung task timeout when they
remove the cable between the PC and the Thunderbolt hub.
This is because the igb_down function is called multiple times when
the Thunderbolt hub is unplugged. For example, the igb_io_error_detected
triggers the first call, and the igb_remove triggers the second call.
The second call to igb_down will block at napi_synchronize.
Here's the call trace:
__schedule+0x3b0/0xddb
? __mod_timer+0x164/0x5d3
schedule+0x44/0xa8
schedule_timeout+0xb2/0x2a4
? run_local_timers+0x4e/0x4e
msleep+0x31/0x38
igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]
__igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]
igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]
__dev_close_many+0x95/0xec
dev_close_many+0x6e/0x103
unregister_netdevice_many+0x105/0x5b1
unregister_netdevice_queue+0xc2/0x10d
unregister_netdev+0x1c/0x23
igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]
pci_device_remove+0x3f/0x9c
device_release_driver_internal+0xfe/0x1b4
pci_stop_bus_device+0x5b/0x7f
pci_stop_bus_device+0x30/0x7f
pci_stop_bus_device+0x30/0x7f
pci_stop_and_remove_bus_device+0x12/0x19
pciehp_unconfigure_device+0x76/0xe9
pciehp_disable_slot+0x6e/0x131
pciehp_handle_presence_or_link_change+0x7a/0x3f7
pciehp_ist+0xbe/0x194
irq_thread_fn+0x22/0x4d
? irq_thread+0x1fd/0x1fd
irq_thread+0x17b/0x1fd
? irq_forced_thread_fn+0x5f/0x5f
kthread+0x142/0x153
? __irq_get_irqchip_state+0x46/0x46
? kthread_associate_blkcg+0x71/0x71
ret_from_fork+0x1f/0x30
In this case, igb_io_error_detected detaches the network interface
and requests a PCIE slot reset, however, the PCIE reset callback is
not being invoked and thus the Ethernet connection breaks down.
As the PCIE error in this case is a non-fatal one, requesting a
slot reset can be avoided.
This patch fixes the task hung issue and preserves Ethernet
connection by ignoring non-fatal PCIE errors.
CVE-2023-53148
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid deadlock in fs reclaim with page writeback
Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:
CPU0 CPU1
ext4_writepages()
percpu_down_read(sbi->s_writepages_rwsem);
ext4_change_inode_journal_flag()
percpu_down_write(sbi->s_writepages_rwsem);
- blocks, all readers block from now on
ext4_do_writepages()
ext4_init_io_end()
kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
fs_reclaim frees dentry...
dentry_unlink_inode()
iput() - last ref =>
iput_final() - inode dirty =>
write_inode_now()...
ext4_writepages() tries to acquire sbi->s_writepages_rwsem
and blocks forever
Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid the deadlock.
CVE-2023-53149
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Pointer may be dereferenced
Klocwork tool reported pointer 'rport' returned from call to function
fc_bsg_to_rport() may be NULL and will be dereferenced.
Add a fix to validate rport before dereferencing.
CVE-2023-53150
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing
writes, raid1 has cond_resched() while raid10 doesn't, and too many
writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for
raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
Call Trace:
<TASK>
call_rcu+0x16/0x20
put_object+0x41/0x80
__delete_object+0x50/0x90
delete_object_full+0x2b/0x40
kmemleak_free+0x46/0xa0
slab_free_freelist_hook.constprop.0+0xed/0x1a0
kmem_cache_free+0xfd/0x300
mempool_free_slab+0x1f/0x30
mempool_free+0x3a/0x100
bio_free+0x59/0x80
bio_put+0xcf/0x2c0
free_r10bio+0xbf/0xf0
raid_end_bio_io+0x78/0xb0
one_write_done+0x8a/0xa0
raid10_end_write_request+0x1b4/0x430
bio_endio+0x175/0x320
brd_submit_bio+0x3b9/0x9b7 [brd]
__submit_bio+0x69/0xe0
submit_bio_noacct_nocheck+0x1e6/0x5a0
submit_bio_noacct+0x38c/0x7e0
flush_pending_writes+0xf0/0x240
raid10d+0xac/0x1ed0
Fix the problem by adding cond_resched() to raid10 like what raid1 did.
Note that unlimited plugged bio still need to be optimized, for example,
in the case of lots of dirty pages writeback, this will take lots of
memory and io will spend a long time in plug, hence io latency is bad.
CVE-2023-53151
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Fix use after free for wext
Key information in wext.connect is not reset on (re)connect and can hold
data from a previous connection.
Reset key data to avoid that drivers or mac80211 incorrectly detect a
WEP connection request and access the freed or already reused memory.
Additionally optimize cfg80211_sme_connect() and avoid an useless
schedule of conn_work.
CVE-2023-53153
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix uninitialized array access for some pathnames
For filenames that begin with . and are between 2 and 5 characters long,
UDF charset conversion code would read uninitialized memory in the
output buffer. The only practical impact is that the name may be prepended a
"unification hash" when it is not actually needed but still it is good
to fix this.
CVE-2023-53165
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix possible memory leak if device_add() fails
If device_add() returns error, the name allocated by dev_set_name() needs
be freed. As the comment of device_add() says, put_device() should be used
to decrease the reference count in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanp().
CVE-2023-53174
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: Reinit port->pm on port specific driver unbind
When we unbind a serial port hardware specific 8250 driver, the generic
serial8250 driver takes over the port. After that we see an oops about 10
seconds later. This can produce the following at least on some TI SoCs:
Unhandled fault: imprecise external abort (0x1406)
Internal error: : 1406 [#1] SMP ARM
Turns out that we may still have the serial port hardware specific driver
port->pm in use, and serial8250_pm() tries to call it after the port
specific driver is gone:
serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]
uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]
uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c
__tty_hangup.part.0 from disassociate_ctty+0x154/0x20c
disassociate_ctty from do_exit+0x744/0xaac
do_exit from do_group_exit+0x40/0x8c
do_group_exit from __wake_up_parent+0x0/0x1c
Let's fix the issue by calling serial8250_set_defaults() in
serial8250_unregister_port(). This will set the port back to using
the serial8250 default functions, and sets the port->pm to point to
serial8250_pm.
CVE-2023-53176
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mm: fix zswap writeback race condition
The zswap writeback mechanism can cause a race condition resulting in
memory corruption, where a swapped out page gets swapped in with data that
was written to a different page.
The race unfolds like this:
1. a page with data A and swap offset X is stored in zswap
2. page A is removed off the LRU by zpool driver for writeback in
zswap-shrink work, data for A is mapped by zpool driver
3. user space program faults and invalidates page entry A, offset X is
considered free
4. kswapd stores page B at offset X in zswap (zswap could also be
full, if so, page B would then be IOed to X, then skip step 5.)
5. entry A is replaced by B in tree->rbroot, this doesn't affect the
local reference held by zswap-shrink work
6. zswap-shrink work writes back A at X, and frees zswap entry A
7. swapin of slot X brings A in memory instead of B
The fix:
Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),
zswap-shrink work just checks that the local zswap_entry reference is
still the same as the one in the tree. If it's not the same it means that
it's either been invalidated or replaced, in both cases the writeback is
aborted because the local entry contains stale data.
Reproducer:
I originally found this by running `stress` overnight to validate my work
on the zswap writeback mechanism, it manifested after hours on my test
machine. The key to make it happen is having zswap writebacks, so
whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do
the trick.
In order to reproduce this faster on a vm, I setup a system with ~100M of
available memory and a 500M swap file, then running `stress --vm 1
--vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens
of minutes. One can speed things up even more by swinging
/sys/module/zswap/parameters/max_pool_percent up and down between, say, 20
and 1; this makes it reproduce in tens of seconds. It's crucial to set
`--vm-stride` to something other than 4096 otherwise `stress` won't
realize that memory has been corrupted because all pages would have the
same data.
CVE-2023-53178
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-53183
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes
A bad USB device is able to construct a service connection response
message with target endpoint being ENDPOINT0 which is reserved for
HTC_CTRL_RSVD_SVC and should not be modified to be used for any other
services.
Reject such service connection responses.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2023-53185
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix race on port output
assume the following setup on a single machine:
1. An openvswitch instance with one bridge and default flows
2. two network namespaces "server" and "client"
3. two ovs interfaces "server" and "client" on the bridge
4. for each ovs interface a veth pair with a matching name and 32 rx and
tx queues
5. move the ends of the veth pairs to the respective network namespaces
6. assign ip addresses to each of the veth ends in the namespaces (needs
to be the same subnet)
7. start some http server on the server network namespace
8. test if a client in the client namespace can reach the http server
when following the actions below the host has a chance of getting a cpu
stuck in a infinite loop:
1. send a large amount of parallel requests to the http server (around
3000 curls should work)
2. in parallel delete the network namespace (do not delete interfaces or
stop the server, just kill the namespace)
there is a low chance that this will cause the below kernel cpu stuck
message. If this does not happen just retry.
Below there is also the output of bpftrace for the functions mentioned
in the output.
The series of events happening here is:
1. the network namespace is deleted calling
`unregister_netdevice_many_notify` somewhere in the process
2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and
then runs `synchronize_net`
3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`
4. this is then handled by `dp_device_event` which calls
`ovs_netdev_detach_dev` (if a vport is found, which is the case for
the veth interface attached to ovs)
5. this removes the rx_handlers of the device but does not prevent
packages to be sent to the device
6. `dp_device_event` then queues the vport deletion to work in
background as a ovs_lock is needed that we do not hold in the
unregistration path
7. `unregister_netdevice_many_notify` continues to call
`netdev_unregister_kobject` which sets `real_num_tx_queues` to 0
8. port deletion continues (but details are not relevant for this issue)
9. at some future point the background task deletes the vport
If after 7. but before 9. a packet is send to the ovs vport (which is
not deleted at this point in time) which forwards it to the
`dev_queue_xmit` flow even though the device is unregistering.
In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is
a while loop (if the packet has a rx_queue recorded) that is infinite if
`dev->real_num_tx_queues` is zero.
To prevent this from happening we update `do_output` to handle devices
without carrier the same as if the device is not found (which would
be the code path after 9. is done).
Additionally we now produce a warning in `skb_tx_hash` if we will hit
the infinite loop.
bpftrace (first word is function name):
__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1
netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1
dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1
synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2
ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2
netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2
synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024
netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2
dp_
---truncated---
CVE-2023-53188
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6/addrconf: fix a potential refcount underflow for idev
Now in addrconf_mod_rs_timer(), reference idev depends on whether
rs_timer is not pending. Then modify rs_timer timeout.
There is a time gap in [1], during which if the pending rs_timer
becomes not pending. It will miss to hold idev, but the rs_timer
is activated. Thus rs_timer callback function addrconf_rs_timer()
will be executed and put idev later without holding idev. A refcount
underflow issue for idev can be caused by this.
if (!timer_pending(&idev->rs_timer))
in6_dev_hold(idev);
<--------------[1]
mod_timer(&idev->rs_timer, jiffies + when);
To fix the issue, hold idev if mod_timer() return 0.
CVE-2023-53189
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains
of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak.
CVE-2023-53191
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails
Syzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream().
While processing skbs in ath9k_hif_usb_rx_stream(), the already allocated
skbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we
have an incorrect pkt_len or pkt_tag, the input skb is considered invalid
and dropped. All the associated packets already in skb_pool should be
dropped and freed. Added a comment describing this issue.
The patch also makes remain_skb NULL after being processed so that it
cannot be referenced after potential free. The initialization of hif_dev
fields which are associated with remain_skb (rx_remain_len,
rx_transfer_len and rx_pad_len) is moved after a new remain_skb is
allocated.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2023-53199
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: wraparound mbox producer index
Driver is not handling the wraparound of the mbox producer index correctly.
Currently the wraparound happens once u32 max is reached.
Bit 31 of the producer index register is special and should be set
only once for the first command. Because the producer index overflow
setting bit31 after a long time, FW goes to initialization sequence
and this causes FW hang.
Fix is to wraparound the mbox producer index once it reaches u16 max.
CVE-2023-53201
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix data-races around user->unix_inflight.
user->unix_inflight is changed under spin_lock(unix_gc_lock),
but too_many_unix_fds() reads it locklessly.
Let's annotate the write/read accesses to user->unix_inflight.
BUG: KCSAN: data-race in unix_attach_fds / unix_inflight
write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1:
unix_inflight+0x157/0x180 net/unix/scm.c:66
unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123
unix_scm_to_skb net/unix/af_unix.c:1827 [inline]
unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950
unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]
unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg+0x148/0x160 net/socket.c:748
____sys_sendmsg+0x4e4/0x610 net/socket.c:2494
___sys_sendmsg+0xc6/0x140 net/socket.c:2548
__sys_sendmsg+0x94/0x140 net/socket.c:2577
__do_sys_sendmsg net/socket.c:2586 [inline]
__se_sys_sendmsg net/socket.c:2584 [inline]
__x64_sys_sendmsg+0x45/0x50 net/socket.c:2584
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0:
too_many_unix_fds net/unix/scm.c:101 [inline]
unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110
unix_scm_to_skb net/unix/af_unix.c:1827 [inline]
unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950
unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]
unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg+0x148/0x160 net/socket.c:748
____sys_sendmsg+0x4e4/0x610 net/socket.c:2494
___sys_sendmsg+0xc6/0x140 net/socket.c:2548
__sys_sendmsg+0x94/0x140 net/socket.c:2577
__do_sys_sendmsg net/socket.c:2586 [inline]
__se_sys_sendmsg net/socket.c:2584 [inline]
__x64_sys_sendmsg+0x45/0x50 net/socket.c:2584
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
value changed: 0x000000000000000c -> 0x000000000000000d
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
CVE-2023-53204
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Don't balance task to its current running CPU
We've run into the case that the balancer tries to balance a migration
disabled task and trigger the warning in set_task_cpu() like below:
------------[ cut here ]------------
WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240
Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip>
CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1
Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021
pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : set_task_cpu+0x188/0x240
lr : load_balance+0x5d0/0xc60
sp : ffff80000803bc70
x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040
x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001
x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78
x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000
x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530
x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e
x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a
x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001
Call trace:
set_task_cpu+0x188/0x240
load_balance+0x5d0/0xc60
rebalance_domains+0x26c/0x380
_nohz_idle_balance.isra.0+0x1e0/0x370
run_rebalance_domains+0x6c/0x80
__do_softirq+0x128/0x3d8
____do_softirq+0x18/0x24
call_on_irq_stack+0x2c/0x38
do_softirq_own_stack+0x24/0x3c
__irq_exit_rcu+0xcc/0xf4
irq_exit_rcu+0x18/0x24
el1_interrupt+0x4c/0xe4
el1h_64_irq_handler+0x18/0x2c
el1h_64_irq+0x74/0x78
arch_cpu_idle+0x18/0x4c
default_idle_call+0x58/0x194
do_idle+0x244/0x2b0
cpu_startup_entry+0x30/0x3c
secondary_start_kernel+0x14c/0x190
__secondary_switched+0xb0/0xb4
---[ end trace 0000000000000000 ]---
Further investigation shows that the warning is superfluous, the migration
disabled task is just going to be migrated to its current running CPU.
This is because that on load balance if the dst_cpu is not allowed by the
task, we'll re-select a new_dst_cpu as a candidate. If no task can be
balanced to dst_cpu we'll try to balance the task to the new_dst_cpu
instead. In this case when the migration disabled task is not on CPU it
only allows to run on its current CPU, load balance will select its
current CPU as new_dst_cpu and later triggers the warning above.
The new_dst_cpu is chosen from the env->dst_grpmask. Currently it
contains CPUs in sched_group_span() and if we have overlapped groups it's
possible to run into this case. This patch makes env->dst_grpmask of
group_balance_mask() which exclude any CPUs from the busiest group and
solve the issue. For balancing in a domain with no overlapped groups
the behaviour keeps same as before.
CVE-2023-53215
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix OOB and integer underflow when rx packets
Make sure mwifiex_process_mgmt_packet,
mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,
mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet
not out-of-bounds access the skb->data buffer.
CVE-2023-53226
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta
Avoid potential data corruption issues caused by uninitialized driver
private data structures.
CVE-2023-53229
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: storvsc: Fix handling of virtual Fibre Channel timeouts
Hyper-V provides the ability to connect Fibre Channel LUNs to the host
system and present them in a guest VM as a SCSI device. I/O to the vFC
device is handled by the storvsc driver. The storvsc driver includes a
partial integration with the FC transport implemented in the generic
portion of the Linux SCSI subsystem so that FC attributes can be displayed
in /sys. However, the partial integration means that some aspects of vFC
don't work properly. Unfortunately, a full and correct integration isn't
practical because of limitations in what Hyper-V provides to the guest.
In particular, in the context of Hyper-V storvsc, the FC transport timeout
function fc_eh_timed_out() causes a kernel panic because it can't find the
rport and dereferences a NULL pointer. The original patch that added the
call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this
regard.
In many cases a timeout is due to a transient condition, so the situation
can be improved by just continuing to wait like with other I/O requests
issued by storvsc, and avoiding the guaranteed panic. For a permanent
failure, continuing to wait may result in a hung thread instead of a panic,
which again may be better.
So fix the panic by removing the storvsc call to fc_eh_timed_out(). This
allows storvsc to keep waiting for a response. The change has been tested
by users who experienced a panic in fc_eh_timed_out() due to transient
timeouts, and it solves their problem.
In the future we may want to deprecate the vFC functionality in storvsc
since it can't be fully fixed. But it has current users for whom it is
working well enough, so it should probably stay for a while longer.
CVE-2023-53245
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL
When compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automount
is NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes to
S_AUTOMOUNT and corresponding dentry flags is retained regardless of
CONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference in
VFS follow_automount() when traversing a DFS referral link:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
<TASK>
__traverse_mounts+0xb5/0x220
? cifs_revalidate_mapping+0x65/0xc0 [cifs]
step_into+0x195/0x610
? lookup_fast+0xe2/0xf0
path_lookupat+0x64/0x140
filename_lookup+0xc2/0x140
? __create_object+0x299/0x380
? kmem_cache_alloc+0x119/0x220
? user_path_at_empty+0x31/0x50
user_path_at_empty+0x31/0x50
__x64_sys_chdir+0x2a/0xd0
? exit_to_user_mode_prepare+0xca/0x100
do_syscall_64+0x42/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
This fix adds an inline cifs_dfs_d_automount() {return -EREMOTE} handler
when CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be to
avoid flagging S_AUTOMOUNT, etc. without CONFIG_CIFS_DFS_UPCALL. This
approach was chosen as it provides more control over the error path.
CVE-2023-53246
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: install stub fence into potential unused fence pointers
When using cpu to update page tables, vm update fences are unused.
Install stub fence into these fence pointers instead of NULL
to avoid NULL dereference when calling dma_fence_wait() on them.
CVE-2023-53248
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 1373 Comm: modprobe
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:dmi_sysfs_entry_release
...
Call Trace:
<TASK>
kobject_put
dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs
dmi_decode_table (drivers/firmware/dmi_scan.c:133)
dmi_walk (drivers/firmware/dmi_scan.c:1115)
dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs
do_one_initcall (init/main.c:1296)
...
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x4000000 from 0xffffffff81000000
---[ end Kernel panic - not syncing: Fatal exception ]---
It is because previous patch added kobject_put() to release the memory
which will call dmi_sysfs_entry_release() and list_del().
However, list_add_tail(entry->list) is called after the error block,
so the list_head is uninitialized and cannot be deleted.
Move error handling to after list_add_tail to fix this.
CVE-2023-53250
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cacheinfo: Fix shared_cpu_map to handle shared caches at different levels
The cacheinfo sets up the shared_cpu_map by checking whether the caches
with the same index are shared between CPUs. However, this will trigger
slab-out-of-bounds access if the CPUs do not have the same cache hierarchy.
Another problem is the mismatched shared_cpu_map when the shared cache does
not have the same index between CPUs.
CPU0 I D L3
index 0 1 2 x
^ ^ ^ ^
index 0 1 2 3
CPU1 I D L2 L3
This patch checks each cache is shared with all caches on other CPUs.
CVE-2023-53254
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ubi: ensure that VID header offset + VID header size <= alloc, size
Ensure that the VID header offset + VID header size does not exceed
the allocated area to avoid slab OOB.
BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197
Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555
CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W
6.0.0-1868 #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29
04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x85/0xad lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433
kasan_report+0xa7/0x11b mm/kasan/report.c:495
crc32_body lib/crc32.c:111 [inline]
crc32_le_generic lib/crc32.c:179 [inline]
crc32_le_base+0x58c/0x626 lib/crc32.c:197
ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067
create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317
create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0x0
RIP: 0033:0x7f96d5cf753d
Code:
RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d
RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003
RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0
R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Allocated by task 1555:
kasan_save_stack+0x20/0x3d mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
____kasan_kmalloc mm/kasan/common.c:516 [inline]
__kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525
kasan_kmalloc include/linux/kasan.h:234 [inline]
__kmalloc+0x138/0x257 mm/slub.c:4429
kmalloc include/linux/slab.h:605 [inline]
ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]
create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295
create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0x0
The buggy address belongs to the object at ffff88802bb36e00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
256-byte region [ffff88802bb36e00, ffff88802bb36f00)
The buggy address belongs to the physical page:
page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x2bb36
head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0
flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40
raw: 0000000000000000 00000000001
---truncated---
CVE-2023-53265
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix i_disksize exceeding i_size problem in paritally written case
It is possible for i_disksize can exceed i_size, triggering a warning.
generic_perform_write
copied = iov_iter_copy_from_user_atomic(len) // copied < len
ext4_da_write_end
| ext4_update_i_disksize
| new_i_size = pos + copied;
| WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize
| generic_write_end
| copied = block_write_end(copied, len) // copied = 0
| if (unlikely(copied < len))
| if (!PageUptodate(page))
| copied = 0;
| if (pos + copied > inode->i_size) // return false
if (unlikely(copied == 0))
goto again;
if (unlikely(iov_iter_fault_in_readable(i, bytes))) {
status = -EFAULT;
break;
}
We get i_disksize greater than i_size here, which could trigger WARNING
check 'i_size_read(inode) < EXT4_I(inode)->i_disksize' while doing dio:
ext4_dio_write_iter
iomap_dio_rw
__iomap_dio_rw // return err, length is not aligned to 512
ext4_handle_inode_extension
WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops
WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319
CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2
RIP: 0010:ext4_file_write_iter+0xbc7
Call Trace:
vfs_write+0x3b1
ksys_write+0x77
do_syscall_64+0x39
Fix it by updating 'copied' value before updating i_disksize just like
ext4_write_inline_data_end() does.
A reproducer can be found in the buganizer link below.
CVE-2023-53270
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
There is a memory leaks problem reported by kmemleak:
unreferenced object 0xffff888102007a00 (size 128):
comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s)
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
[<ffffffff8176cecd>] __kmalloc+0x4d/0x150
[<ffffffffa02a9a36>] ubi_eba_create_table+0x76/0x170 [ubi]
[<ffffffffa029764e>] ubi_resize_volume+0x1be/0xbc0 [ubi]
[<ffffffffa02a3321>] ubi_cdev_ioctl+0x701/0x1850 [ubi]
[<ffffffff81975d2d>] __x64_sys_ioctl+0x11d/0x170
[<ffffffff83c142a5>] do_syscall_64+0x35/0x80
[<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
This is due to a mismatch between create and destroy interfaces, and
in detail that "new_eba_tbl" created by ubi_eba_create_table() but
destroyed by kfree(), while will causing "new_eba_tbl->entries" not
freed.
Fix it by replacing kfree(new_eba_tbl) with
ubi_eba_destroy_table(new_eba_tbl)
CVE-2023-53271
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
net: ena: fix shift-out-of-bounds in exponential backoff
The ENA adapters on our instances occasionally reset. Once recently
logged a UBSAN failure to console in the process:
UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117
Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017
Workqueue: ena ena_fw_reset_device [ena]
Call Trace:
<TASK>
dump_stack_lvl+0x4a/0x63
dump_stack+0x10/0x16
ubsan_epilogue+0x9/0x36
__ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
? __const_udelay+0x43/0x50
ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena]
wait_for_reset_state+0x54/0xa0 [ena]
ena_com_dev_reset+0xc8/0x110 [ena]
ena_down+0x3fe/0x480 [ena]
ena_destroy_device+0xeb/0xf0 [ena]
ena_fw_reset_device+0x30/0x50 [ena]
process_one_work+0x22b/0x3d0
worker_thread+0x4d/0x3f0
? process_one_work+0x3d0/0x3d0
kthread+0x12a/0x150
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
</TASK>
Apparently, the reset delays are getting so large they can trigger a
UBSAN panic.
Looking at the code, the current timeout is capped at 5000us. Using a
base value of 100us, the current code will overflow after (1<<29). Even
at values before 32, this function wraps around, perhaps
unintentionally.
Cap the value of the exponent used for this backoff at (1<<16) which is
larger than currently necessary, but large enough to support bigger
values in the future.
CVE-2023-53272
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwl3945: Add missing check for create_singlethread_workqueue
Add the check for the return value of the create_singlethread_workqueue
in order to avoid NULL pointer dereference.
CVE-2023-53277
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue
System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up
gets called for uninitialized wait queue sp->nvme_ls_waitq.
qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0
qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
RIP: 0010:__wake_up_common+0x4c/0x190
RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
__wake_up_common_lock+0x7c/0xc0
qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]
Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed
previously in the commits tagged Fixed: below.
CVE-2023-53280
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is
logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]
Use-after-free read at 0x0000000000cf164d (in kfence-#111):
lpfc_wr_object+0x235/0x310 [lpfc]
lpfc_write_firmware.cold+0x206/0x30d [lpfc]
lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]
lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]
kernfs_fop_write_iter+0x121/0x1b0
new_sync_write+0x11c/0x1b0
vfs_write+0x1ef/0x280
ksys_write+0x5f/0xe0
do_syscall_64+0x59/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into
mailbox payload memory, after the mailbox object was released back to the
mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring
that we don't reference internal mailbox memory after release.
CVE-2023-53282
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fix memory leak in drm_client_modeset_probe
When a new mode is set to modeset->mode, the previous mode should be freed.
This fixes the following kmemleak report:
drm_mode_duplicate+0x45/0x220 [drm]
drm_client_modeset_probe+0x944/0xf50 [drm]
__drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]
drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]
drm_client_register+0x169/0x240 [drm]
ast_pci_probe+0x142/0x190 [ast]
local_pci_probe+0xdc/0x180
work_for_cpu_fn+0x4e/0xa0
process_one_work+0x8b7/0x1540
worker_thread+0x70a/0xed0
kthread+0x29f/0x340
ret_from_fork+0x1f/0x30
CVE-2023-53288
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: bdisp: Add missing check for create_workqueue
Add the check for the return value of the create_workqueue
in order to avoid NULL pointer dereference.
CVE-2023-53289
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none
After grabbing q->sysfs_lock, q->elevator may become NULL because of
elevator switch.
Fix the NULL dereference on q->elevator by checking it with lock.
CVE-2023-53292
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
udf: Do not update file length for failed writes to inline files
When write to inline file fails (or happens only partly), we still
updated length of inline data as if the whole write succeeded. Fix the
update of length of inline data to happen only if the write succeeds.
CVE-2023-53295
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: fix memory leak of se_io context in nfc_genl_se_io
The callback context for sending/receiving APDUs to/from the selected
secure element is allocated inside nfc_genl_se_io and supposed to be
eventually freed in se_io_cb callback function. However, there are several
error paths where the bwi_timer is not charged to call se_io_cb later, and
the cb_context is leaked.
The patch proposes to free the cb_context explicitly on those error paths.
At the moment we can't simply check 'dev->ops->se_io()' return value as it
may be negative in both cases: when the timer was charged and was not.
CVE-2023-53298
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix leak of 'r10bio->remaining' for recovery
raid10_sync_request() will add 'r10bio->remaining' for both rdev and
replacement rdev. However, if the read io fails, recovery_request_write()
returns without issuing the write io, in this case, end_sync_request()
is only called once and 'remaining' is leaked, cause an io hang.
Fix the problem by decreasing 'remaining' according to if 'bio' and
'repl_bio' is valid.
CVE-2023-53299
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwl4965: Add missing check for create_singlethread_workqueue()
Add the check for the return value of the create_singlethread_workqueue()
in order to avoid NULL pointer dereference.
CVE-2023-53302
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free
Fix potential use-after-free in l2cap_le_command_rej.
CVE-2023-53305
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails
If getting an ID or setting up a work queue in rbd_dev_create() fails,
use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts
is triggered in do_rbd_add(). The root cause is that the ownership of
these structures is transfered to rbd_dev prematurely and they all end
up getting freed when rbd_dev_create() calls rbd_dev_free() prior to
returning to do_rbd_add().
Found by Linux Verification Center (linuxtesting.org) with SVACE, an
incomplete patch submitted by Natalia Petrova <n.petrova@fintech.ru>.
CVE-2023-53307
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fec: Better handle pm_runtime_get() failing in .remove()
In the (unlikely) event that pm_runtime_get() (disguised as
pm_runtime_resume_and_get()) fails, the remove callback returned an
error early. The problem with this is that the driver core ignores the
error value and continues removing the device. This results in a
resource leak. Worse the devm allocated resources are freed and so if a
callback of the driver is called later the register mapping is already
gone which probably results in a crash.
CVE-2023-53308
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: Fix integer overflow in radeon_cs_parser_init
The type of size is unsigned, if size is 0x40000000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later
CVE-2023-53309
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix wrong setting of max_corr_read_errors
There is no input check when echo md/max_read_errors and overflow might
occur. Add check of input number.
CVE-2023-53313
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in mb_find_extent
Syzbot found the following issue:
EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
EXT4-fs (loop0): orphan cleanup on readonly fs
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
Modules linked in:
CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869
RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293
RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0
RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040
RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402
R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000
R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc
FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307
ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735
ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605
ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286
ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651
ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864
ext4_bread+0x2a/0x170 fs/ext4/inode.c:920
ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105
write_blk fs/quota/quota_tree.c:64 [inline]
get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130
do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340
do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375
dq_insert_tree fs/quota/quota_tree.c:401 [inline]
qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420
v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358
dquot_acquire+0x348/0x670 fs/quota/dquot.c:444
ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740
dqget+0x999/0xdc0 fs/quota/dquot.c:914
__dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492
ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329
ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474
__ext4_fill_super fs/ext4/super.c:5516 [inline]
ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
get_tree_bdev+0x400/0x620 fs/super.c:1282
vfs_get_tree+0x88/0x270 fs/super.c:1489
do_new_mount+0x289/0xad0 fs/namespace.c:3145
do_mount fs/namespace.c:3488 [inline]
__do_sys_mount fs/namespace.c:3697 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Add some debug information:
mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7
block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Acctually, blocks per group is 64, but block bitmap indicate at least has
128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block's
bitmap if set.
To resolve above issue, add check like fsck "Padding at end of block bitmap is
not set".
CVE-2023-53317
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211_hwsim: drop short frames
While technically some control frames like ACK are shorter and
end after Address 1, such frames shouldn't be forwarded through
wmediumd or similar userspace, so require the full 3-address
header to avoid accessing invalid memory if shorter frames are
passed in.
CVE-2023-53321
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Wait for io return on terminate rport
System crash due to use after free.
Current code allows terminate_rport_io to exit before making
sure all IOs has returned. For FCP-2 device, IO's can hang
on in HW because driver has not tear down the session in FW at
first sign of cable pull. When dev_loss_tmo timer pops,
terminate_rport_io is called and upper layer is about to
free various resources. Terminate_rport_io trigger qla to do
the final cleanup, but the cleanup might not be fast enough where it
leave qla still holding on to the same resource.
Wait for IO's to return to upper layer before resources are freed.
CVE-2023-53322
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Don't try to copy PPR for task with NULL pt_regs
powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
from my (arguably very short) checking is not commonly done for other
archs. This is fine, except when PF_IO_WORKER's have been created and
the task does something that causes a coredump to be generated. Then we
get this crash:
Kernel attempted to read user page (160) - exploit attempt? (uid: 1000)
BUG: Kernel NULL pointer dereference on read at 0x00000160
Faulting instruction address: 0xc0000000000c3a60
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries
Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod
CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
NIP: c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0
REGS: c0000000041833b0 TRAP: 0300 Not tainted (6.3.0-rc2+)
MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 88082828 XER: 200400f8
...
NIP memcpy_power7+0x200/0x7d0
LR ppr_get+0x64/0xb0
Call Trace:
ppr_get+0x40/0xb0 (unreliable)
__regset_get+0x180/0x1f0
regset_get_alloc+0x64/0x90
elf_core_dump+0xb98/0x1b60
do_coredump+0x1c34/0x24a0
get_signal+0x71c/0x1410
do_notify_resume+0x140/0x6f0
interrupt_exit_user_prepare_main+0x29c/0x320
interrupt_exit_user_prepare+0x6c/0xa0
interrupt_return_srr_user+0x8/0x138
Because ppr_get() is trying to copy from a PF_IO_WORKER with a NULL
pt_regs.
Check for a valid pt_regs in both ppc_get/ppr_set, and return an error
if not set. The actual error value doesn't seem to be important here, so
just pick -EINVAL.
[mpe: Trim oops in change log, add Fixes & Cc stable]
CVE-2023-53326
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pstore/ram: Check start of empty przs during init
After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as
valid"), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:
sysdump_panic_event+0x3b4/0x5b8
atomic_notifier_call_chain+0x54/0x90
panic+0x1c8/0x42c
die+0x29c/0x2a8
die_kernel_fault+0x68/0x78
__do_kernel_fault+0x1c4/0x1e0
do_bad_area+0x40/0x100
do_translation_fault+0x68/0x80
do_mem_abort+0x68/0xf8
el1_da+0x1c/0xc0
__raw_writeb+0x38/0x174
__memcpy_toio+0x40/0xac
persistent_ram_update+0x44/0x12c
persistent_ram_write+0x1a8/0x1b8
ramoops_pstore_write+0x198/0x1e8
pstore_console_write+0x94/0xe0
...
To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start >
size) and zap the buffer back to a sane state.
[kees: update commit log with backtrace and clarifications]
CVE-2023-53331
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()
If ipi_send_{mask|single}() is called with an invalid interrupt number, all
the local variables there will be NULL. ipi_send_verify() which is invoked
from these functions does verify its 'data' parameter, resulting in a
kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets
dereferenced.
Add a missing NULL pointer check in ipi_send_verify()...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
CVE-2023-53332
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()
If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is
dereferenced later regardless of whether it is empty.
This patch adds a simple sanity check to fix the issue.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-53335
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
lwt: Fix return values of BPF xmit ops
BPF encap ops can return different types of positive values, such like
NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function
skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return
values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in
ip(6)_finish_output2. When this happens, skbs that have been freed would
continue to the neighbor subsystem, causing use-after-free bug and
kernel crashes.
To fix the incorrect behavior, skb_do_redirect return values can be
simply discarded, the same as tc-egress behavior. On the other hand,
bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU
information. Thus convert its return values to avoid the conflict with
LWTUNNEL_XMIT_CONTINUE.
CVE-2023-53338
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix BUG_ON condition in btrfs_cancel_balance
Pausing and canceling balance can race to interrupt balance lead to BUG_ON
panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance
does not take this race scenario into account.
However, the race condition has no other side effects. We can fix that.
Reproducing it with panic trace like this:
kernel BUG at fs/btrfs/volumes.c:4618!
RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0
Call Trace:
<TASK>
? do_nanosleep+0x60/0x120
? hrtimer_nanosleep+0xb7/0x1a0
? sched_core_clone_cookie+0x70/0x70
btrfs_ioctl_balance_ctl+0x55/0x70
btrfs_ioctl+0xa46/0xd20
__x64_sys_ioctl+0x7d/0xa0
do_syscall_64+0x38/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Race scenario as follows:
> mutex_unlock(&fs_info->balance_mutex);
> --------------------
> .......issue pause and cancel req in another thread
> --------------------
> ret = __btrfs_balance(fs_info);
>
> mutex_lock(&fs_info->balance_mutex);
> if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) {
> btrfs_info(fs_info, "balance: paused");
> btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);
> }
CVE-2023-53339
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write
Syzkaller reported the following issue:
=====================================================
BUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]
BUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600
aio_rw_done fs/aio.c:1520 [inline]
aio_write+0x899/0x950 fs/aio.c:1600
io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
__do_sys_io_submit fs/aio.c:2078 [inline]
__se_sys_io_submit+0x293/0x770 fs/aio.c:2048
__x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at:
slab_post_alloc_hook mm/slab.h:766 [inline]
slab_alloc_node mm/slub.c:3452 [inline]
__kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491
__do_kmalloc_node mm/slab_common.c:967 [inline]
__kmalloc+0x11d/0x3b0 mm/slab_common.c:981
kmalloc_array include/linux/slab.h:636 [inline]
bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930
bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
sock_write_iter+0x495/0x5e0 net/socket.c:1108
call_write_iter include/linux/fs.h:2189 [inline]
aio_write+0x63a/0x950 fs/aio.c:1600
io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019
__do_sys_io_submit fs/aio.c:2078 [inline]
__se_sys_io_submit+0x293/0x770 fs/aio.c:2048
__x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
CPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
=====================================================
We can follow the call chain and find that 'bcm_tx_setup' function
calls 'memcpy_from_msg' to copy some content to the newly allocated
frame of 'op->frames'. After that the 'len' field of copied structure
being compared with some constant value (64 or 8). However, if
'memcpy_from_msg' returns an error, we will compare some uninitialized
memory. This triggers 'uninit-value' issue.
This patch will add 'memcpy_from_msg' possible errors processing to
avoid uninit-value issue.
Tested via syzkaller
CVE-2023-53344
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when aborting transaction during relocation with scrub
Before relocating a block group we pause scrub, then do the relocation and
then unpause scrub. The relocation process requires starting and committing
a transaction, and if we have a failure in the critical section of the
transaction commit path (transaction state >= TRANS_STATE_COMMIT_START),
we will deadlock if there is a paused scrub.
That results in stack traces like the following:
[42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6
[42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction.
[42.936] ------------[ cut here ]------------
[42.936] BTRFS: Transaction aborted (error -28)
[42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]
[42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...)
[42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1
[42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]
[42.936] Code: ff ff 45 8b (...)
[42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282
[42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000
[42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff
[42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8
[42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00
[42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0
[42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000
[42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0
[42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[42.936] Call Trace:
[42.936] <TASK>
[42.936] ? start_transaction+0xcb/0x610 [btrfs]
[42.936] prepare_to_relocate+0x111/0x1a0 [btrfs]
[42.936] relocate_block_group+0x57/0x5d0 [btrfs]
[42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs]
[42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs]
[42.936] ? __pfx_autoremove_wake_function+0x10/0x10
[42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs]
[42.936] btrfs_balance+0x8ff/0x11d0 [btrfs]
[42.936] ? __kmem_cache_alloc_node+0x14a/0x410
[42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs]
[42.937] ? mod_objcg_state+0xd2/0x360
[42.937] ? refill_obj_stock+0xb0/0x160
[42.937] ? seq_release+0x25/0x30
[42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0
[42.937] ? percpu_counter_add_batch+0x2e/0xa0
[42.937] ? __x64_sys_ioctl+0x88/0xc0
[42.937] __x64_sys_ioctl+0x88/0xc0
[42.937] do_syscall_64+0x38/0x90
[42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[42.937] RIP: 0033:0x7f381a6ffe9b
[42.937] Code: 00 48 89 44 24 (...)
[42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b
[42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003
[42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000
[42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423
[42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148
[42.937] </TASK>
[42.937] ---[ end trace 0000000000000000 ]---
[42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left
[59.196] INFO: task btrfs:346772 blocked for more than 120 seconds.
[59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1
[59.196] "echo 0 > /proc/sys/kernel/hung_
---truncated---
CVE-2023-53348
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: check slab-out-of-bounds in md_bitmap_get_counter
If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()
will return -EINVAL because 'page >= bitmap->pages', but the return value
was not checked immediately in md_bitmap_get_counter() in order to set
*blocks value and slab-out-of-bounds occurs.
Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() and
return directly if true.
CVE-2023-53357
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: Fix skb_under_panic in ip6mr_cache_report()
skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4
head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:192!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:skb_panic+0x152/0x1d0
Call Trace:
<TASK>
skb_push+0xc4/0xe0
ip6mr_cache_report+0xd69/0x19b0
reg_vif_xmit+0x406/0x690
dev_hard_start_xmit+0x17e/0x6e0
__dev_queue_xmit+0x2d6a/0x3d20
vlan_dev_hard_start_xmit+0x3ab/0x5c0
dev_hard_start_xmit+0x17e/0x6e0
__dev_queue_xmit+0x2d6a/0x3d20
neigh_connected_output+0x3ed/0x570
ip6_finish_output2+0x5b5/0x1950
ip6_finish_output+0x693/0x11c0
ip6_output+0x24b/0x880
NF_HOOK.constprop.0+0xfd/0x530
ndisc_send_skb+0x9db/0x1400
ndisc_send_rs+0x12a/0x6c0
addrconf_dad_completed+0x3c9/0xea0
addrconf_dad_work+0x849/0x1420
process_one_work+0xa22/0x16e0
worker_thread+0x679/0x10c0
ret_from_fork+0x28/0x60
ret_from_fork_asm+0x11/0x20
When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().
reg_vif_xmit()
ip6mr_cache_report()
skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4
And skb_push declared as:
void *skb_push(struct sk_buff *skb, unsigned int len);
skb->data -= len;
//0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850
skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.
CVE-2023-53365
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix race issue between cpu buffer write and swap
Warning happened in rb_end_commit() at code:
if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)))
WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142
rb_commit+0x402/0x4a0
Call Trace:
ring_buffer_unlock_commit+0x42/0x250
trace_buffer_unlock_commit_regs+0x3b/0x250
trace_event_buffer_commit+0xe5/0x440
trace_event_buffer_reserve+0x11c/0x150
trace_event_raw_event_sched_switch+0x23c/0x2c0
__traceiter_sched_switch+0x59/0x80
__schedule+0x72b/0x1580
schedule+0x92/0x120
worker_thread+0xa0/0x6f0
It is because the race between writing event into cpu buffer and swapping
cpu buffer through file per_cpu/cpu0/snapshot:
Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1
-------- --------
tracing_snapshot_write()
[...]
ring_buffer_lock_reserve()
cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a';
[...]
rb_reserve_next_event()
[...]
ring_buffer_swap_cpu()
if (local_read(&cpu_buffer_a->committing))
goto out_dec;
if (local_read(&cpu_buffer_b->committing))
goto out_dec;
buffer_a->buffers[cpu] = cpu_buffer_b;
buffer_b->buffers[cpu] = cpu_buffer_a;
// 2. cpu_buffer has swapped here.
rb_start_commit(cpu_buffer);
if (unlikely(READ_ONCE(cpu_buffer->buffer)
!= buffer)) { // 3. This check passed due to 'cpu_buffer->buffer'
[...] // has not changed here.
return NULL;
}
cpu_buffer_b->buffer = buffer_a;
cpu_buffer_a->buffer = buffer_b;
[...]
// 4. Reserve event from 'cpu_buffer_a'.
ring_buffer_unlock_commit()
[...]
cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!!
rb_commit(cpu_buffer)
rb_end_commit() // 6. WARN for the wrong 'committing' state !!!
Based on above analysis, we can easily reproduce by following testcase:
``` bash
#!/bin/bash
dmesg -n 7
sysctl -w kernel.panic_on_warn=1
TR=/sys/kernel/tracing
echo 7 > ${TR}/buffer_size_kb
echo "sched:sched_switch" > ${TR}/set_event
while [ true ]; do
echo 1 > ${TR}/per_cpu/cpu0/snapshot
done &
while [ true ]; do
echo 1 > ${TR}/per_cpu/cpu0/snapshot
done &
while [ true ]; do
echo 1 > ${TR}/per_cpu/cpu0/snapshot
done &
```
To fix it, IIUC, we can use smp_call_function_single() to do the swap on
the target cpu where the buffer is located, so that above race would be
avoided.
CVE-2023-53368
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: dcb: choose correct policy to parse DCB_ATTR_BCN
The dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],
which is introduced in commit 859ee3c43812 ("DCB: Add support for DCB
BCN"). Please see the comment in below code
static int dcbnl_bcn_setcfg(...)
{
...
ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )
// !!! dcbnl_pfc_up_nest for attributes
// DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs
...
for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) {
// !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs
...
value_byte = nla_get_u8(data[i]);
...
}
...
for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) {
// !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs
...
value_int = nla_get_u32(data[i]);
...
}
...
}
That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest
attributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the
following access code fetch each nlattr as dcbnl_bcn_attrs attributes.
By looking up the associated nla_policy for dcbnl_bcn_attrs. We can find
the beginning part of these two policies are "same".
static const struct nla_policy dcbnl_pfc_up_nest[...] = {
[DCB_PFC_UP_ATTR_0] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_1] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_2] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_3] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_4] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_5] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_6] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_7] = {.type = NLA_U8},
[DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},
};
static const struct nla_policy dcbnl_bcn_nest[...] = {
[DCB_BCN_ATTR_RP_0] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_1] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_2] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_3] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_4] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_5] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_6] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_7] = {.type = NLA_U8},
[DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG},
// from here is somewhat different
[DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32},
...
[DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},
};
Therefore, the current code is buggy and this
nla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use
the adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.
Hence use the correct policy dcbnl_bcn_nest to parse the nested
tb[DCB_ATTR_BCN] TLV.
CVE-2023-53369
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: seqiv - Handle EBUSY correctly
As it is seqiv only handles the special return value of EINPROGERSS,
which means that in all other cases it will free data related to the
request.
However, as the caller of seqiv may specify MAY_BACKLOG, we also need
to expect EBUSY and treat it in the same way. Otherwise backlogged
requests will trigger a use-after-free.
CVE-2023-53373
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request
There are two check of 'mreplace' in raid10_sync_request(). In the first
check, 'need_replace' will be set and 'mreplace' will be used later if
no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be
set to NULL if it is Faulty, but 'need_replace' will not be changed
accordingly. null-ptr-deref occurs if Faulty is set between two check.
Fix it by merging two checks into one. And replace 'need_replace' with
'mreplace' because their values are always the same.
CVE-2023-53380
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: avoid possible NULL skb pointer dereference
In 'mwifiex_handle_uap_rx_forward()', always check the value
returned by 'skb_copy()' to avoid potential NULL pointer
dereference in 'mwifiex_uap_queue_bridged_pkt()', and drop
original skb in case of copying failure.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-53384
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device
Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),
there is a special handling in order to use the correct counters, but,
port_num is being passed down the stack without any change. Also, some
functions assume that port_num >=1. As a result, the following oops can
occur.
BUG: unable to handle page fault for address: ffff89510294f1a8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP
CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:_raw_spin_lock+0xc/0x20
Call Trace:
<TASK>
mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib]
do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib]
mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib]
ib_setup_device_attrs+0xf0/0x290 [ib_core]
ib_register_device+0x3bb/0x510 [ib_core]
? atomic_notifier_chain_register+0x67/0x80
__mlx5_ib_add+0x2b/0x80 [mlx5_ib]
mlx5r_probe+0xb8/0x150 [mlx5_ib]
? auxiliary_match_id+0x6a/0x90
auxiliary_bus_probe+0x3c/0x70
? driver_sysfs_add+0x6b/0x90
really_probe+0xcd/0x380
__driver_probe_device+0x80/0x170
driver_probe_device+0x1e/0x90
__device_attach_driver+0x7d/0x100
? driver_allows_async_probing+0x60/0x60
? driver_allows_async_probing+0x60/0x60
bus_for_each_drv+0x7b/0xc0
__device_attach+0xbc/0x200
bus_probe_device+0x87/0xa0
device_add+0x404/0x940
? dev_set_name+0x53/0x70
__auxiliary_device_add+0x43/0x60
add_adev+0x99/0xe0 [mlx5_core]
mlx5_attach_device+0xc8/0x120 [mlx5_core]
mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core]
devlink_reload+0x133/0x250
devlink_nl_cmd_reload+0x480/0x570
? devlink_nl_pre_doit+0x44/0x2b0
genl_family_rcv_msg_doit.isra.0+0xc2/0x110
genl_rcv_msg+0x180/0x2b0
? devlink_nl_cmd_region_read_dumpit+0x540/0x540
? devlink_reload+0x250/0x250
? devlink_put+0x50/0x50
? genl_family_rcv_msg_doit.isra.0+0x110/0x110
netlink_rcv_skb+0x54/0x100
genl_rcv+0x24/0x40
netlink_unicast+0x1f6/0x2c0
netlink_sendmsg+0x237/0x490
sock_sendmsg+0x33/0x40
__sys_sendto+0x103/0x160
? handle_mm_fault+0x10e/0x290
? do_user_addr_fault+0x1c0/0x5f0
__x64_sys_sendto+0x25/0x30
do_syscall_64+0x3d/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Fix it by setting port_num to 1 in order to get device status and remove
unused variable.
CVE-2023-53393
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer
ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5
According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.
When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.
=============================================================
UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]'
CPU: 37 PID: 1678 Comm: cat Not tainted
6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k
HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:
dump_backtrace+0xe0/0x130
show_stack+0x20/0x60
dump_stack_lvl+0x68/0x84
dump_stack+0x18/0x34
ubsan_epilogue+0x10/0x50
__ubsan_handle_out_of_bounds+0x80/0x90
acpi_ds_exec_end_op+0x1bc/0x6d8
acpi_ps_parse_loop+0x57c/0x618
acpi_ps_parse_aml+0x1e0/0x4b4
acpi_ps_execute_method+0x24c/0x2b8
acpi_ns_evaluate+0x3a8/0x4bc
acpi_evaluate_object+0x15c/0x37c
acpi_evaluate_integer+0x54/0x15c
show_power+0x8c/0x12c [acpi_power_meter]
CVE-2023-53395
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
modpost: fix off by one in is_executable_section()
The > comparison should be >= to prevent an out of bounds array
access.
CVE-2023-53397
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: Fix Oops by 9.1 surround channel names
get_line_out_pfx() may trigger an Oops by overflowing the static array
with more than 8 channels. This was reported for MacBookPro 12,1 with
Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the
potential Oops by unifying the code paths accessing the same array
with the proper size check.
CVE-2023-53400
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix warning and UAF when destroy the MR list
If the MR allocate failed, the MR recovery work not initialized
and list not cleared. Then will be warning and UAF when release
the MR:
WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110
CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82
RIP: 0010:__flush_work.isra.0+0xf7/0x110
Call Trace:
<TASK>
__cancel_work_timer+0x2ba/0x2e0
smbd_destroy+0x4e1/0x990
_smbd_get_connection+0x1cbd/0x2110
smbd_get_connection+0x21/0x40
cifs_get_tcp_session+0x8ef/0xda0
mount_get_conns+0x60/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
BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990
Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824
CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82
Call Trace:
dump_stack_lvl+0x34/0x44
print_report+0x171/0x472
kasan_report+0xad/0x130
smbd_destroy+0x4fc/0x990
_smbd_get_connection+0x1cbd/0x2110
smbd_get_connection+0x21/0x40
cifs_get_tcp_session+0x8ef/0xda0
mount_get_conns+0x60/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
Allocated by task 824:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_kmalloc+0x7a/0x90
_smbd_get_connection+0x1b6f/0x2110
smbd_get_connection+0x21/0x40
cifs_get_tcp_session+0x8ef/0xda0
mount_get_conns+0x60/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
Freed by task 824:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
____kasan_slab_free+0x143/0x1b0
__kmem_cache_free+0xc8/0x330
_smbd_get_connection+0x1c6a/0x2110
smbd_get_connection+0x21/0x40
cifs_get_tcp_session+0x8ef/0xda0
mount_get_conns+0x60/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
Let's initialize the MR recovery work before MR allocate to prevent
the warning, remove the MRs from the list to prevent the UAF.
CVE-2023-53427
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Handle enclosure with just a primary component gracefully
This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure
has no components") and introduces proper handling of case where there are
no detected secondary components, but primary component (enumerated in
num_enclosures) does exist. That fix was originally proposed by Ding Hui
<dinghui@sangfor.com.cn>.
Completely ignoring devices that have one primary enclosure and no
secondary one results in ses_intf_add() bailing completely
scsi 2:0:0:254: enclosure has no enumerated components
scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such
even on valid configurations with 1 primary and 0 secondary enclosures as
below:
# sg_ses /dev/sg0
3PARdata SES 3321
Supported diagnostic pages:
Supported Diagnostic Pages [sdp] [0x0]
Configuration (SES) [cf] [0x1]
Short Enclosure Status (SES) [ses] [0x8]
# sg_ses -p cf /dev/sg0
3PARdata SES 3321
Configuration diagnostic page:
number of secondary subenclosures: 0
generation code: 0x0
enclosure descriptor list
Subenclosure identifier: 0 [primary]
relative ES process id: 0, number of ES processes: 1
number of type descriptor headers: 1
enclosure logical identifier (hex): 20000002ac02068d
enclosure vendor: 3PARdata product: VV rev: 3321
type descriptor header and text list
Element type: Unspecified, subenclosure id: 0
number of possible elements: 1
The changelog for the original fix follows
=====
We can get a crash when disconnecting the iSCSI session,
the call trace like this:
[ffff00002a00fb70] kfree at ffff00000830e224
[ffff00002a00fba0] ses_intf_remove at ffff000001f200e4
[ffff00002a00fbd0] device_del at ffff0000086b6a98
[ffff00002a00fc50] device_unregister at ffff0000086b6d58
[ffff00002a00fc70] __scsi_remove_device at ffff00000870608c
[ffff00002a00fca0] scsi_remove_device at ffff000008706134
[ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4
[ffff00002a00fd10] scsi_remove_target at ffff0000087064c0
[ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4
[ffff00002a00fdb0] process_one_work at ffff00000810f35c
[ffff00002a00fe00] worker_thread at ffff00000810f648
[ffff00002a00fe70] kthread at ffff000008116e98
In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,
but not saved in edev->component[i].scratch
In this situation, edev->component[0].scratch is an invalid pointer,
when kfree it in ses_intf_remove_enclosure, a crash like above would happen
The call trace also could be other random cases when kfree cannot catch
the invalid pointer
We should not use edev->component[] array when the components count is 0
We also need check index when use edev->component[] array in
ses_enclosure_data_process
=====
CVE-2023-53431
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: add vlan_get_protocol_and_depth() helper
Before blamed commit, pskb_may_pull() was used instead
of skb_header_pointer() in __vlan_get_protocol() and friends.
Few callers depended on skb->head being populated with MAC header,
syzbot caught one of them (skb_mac_gso_segment())
Add vlan_get_protocol_and_depth() to make the intent clearer
and use it where sensible.
This is a more generic fix than commit e9d3f80935b6
("net/af_packet: make sure to pull mac header") which was
dealing with a similar issue.
kernel BUG at include/linux/skbuff.h:2655 !
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]
RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136
Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286
RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9
R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012
R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7
FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
[<ffffffff847018dd>] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419
[<ffffffff8470398a>] skb_gso_segment include/linux/netdevice.h:4819 [inline]
[<ffffffff8470398a>] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725
[<ffffffff84707042>] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313
[<ffffffff851a9ec7>] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029
[<ffffffff851b4a82>] packet_snd net/packet/af_packet.c:3111 [inline]
[<ffffffff851b4a82>] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142
[<ffffffff84669a12>] sock_sendmsg_nosec net/socket.c:716 [inline]
[<ffffffff84669a12>] sock_sendmsg net/socket.c:736 [inline]
[<ffffffff84669a12>] __sys_sendto+0x472/0x5f0 net/socket.c:2139
[<ffffffff84669c75>] __do_sys_sendto net/socket.c:2151 [inline]
[<ffffffff84669c75>] __se_sys_sendto net/socket.c:2147 [inline]
[<ffffffff84669c75>] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147
[<ffffffff8551d40f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff8551d40f>] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80
[<ffffffff85600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVE-2023-53433
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: snic: Fix possible memory leak if device_add() fails
If device_add() returns error, the name allocated by dev_set_name() needs
be freed. As the comment of device_add() says, put_device() should be used
to give up the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanp().
CVE-2023-53436
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/MCE: Always save CS register on AMD Zen IF Poison errors
The Instruction Fetch (IF) units on current AMD Zen-based systems do not
guarantee a synchronous #MC is delivered for poison consumption errors.
Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the
microarchitecture does guarantee that the exception is delivered within
the same context. In other words, the exact rIP is not known, but the
context is known to not have changed.
There is no architecturally-defined method to determine this behavior.
The Code Segment (CS) register is always valid on such IF unit poison
errors regardless of the value of MCG_STATUS[EIPV|RIPV].
Add a quirk to save the CS register for poison consumption from the IF
unit banks.
This is needed to properly determine the context of the error.
Otherwise, the severity grading function will assume the context is
IN_KERNEL due to the m->cs value being 0 (the initialized value). This
leads to unnecessary kernel panics on data poison errors due to the
kernel believing the poison consumption occurred in kernel context.
CVE-2023-53438
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1969.
CVE-2023-5344
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: cpumap: Fix memory leak in cpu_map_update_elem
Syzkaller reported a memory leak as follows:
BUG: memory leak
unreferenced object 0xff110001198ef748 (size 192):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 32 bytes):
00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........
00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......
backtrace:
[<ffffffffadd28087>] __cpu_map_entry_alloc+0xf7/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
BUG: memory leak
unreferenced object 0xff110001198ef528 (size 192):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffadd281f0>] __cpu_map_entry_alloc+0x260/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
BUG: memory leak
unreferenced object 0xff1100010fd93d68 (size 8):
comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00 ........
backtrace:
[<ffffffffade5db3e>] kvmalloc_node+0x11e/0x170
[<ffffffffadd28280>] __cpu_map_entry_alloc+0x2f0/0xb00
[<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0
[<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520
[<ffffffffadc7349b>] map_update_elem+0x4cb/0x720
[<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90
[<ffffffffb029cc80>] do_syscall_64+0x30/0x40
[<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
In the cpu_map_update_elem flow, when kthread_stop is called before
calling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit
of kthread has been set by kthread_stop, the threadfn of rcpu->kthread
will never be executed, and rcpu->refcnt will never be 0, which will
lead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot be
released.
Calling kthread_stop before executing kthread's threadfn will return
-EINTR. We can complete the release of memory resources in this state.
CVE-2023-53441
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free
Struct pcie_link_state->downstream is a pointer to the pci_dev of function
0. Previously we retained that pointer when removing function 0, and
subsequent ASPM policy changes dereferenced it, resulting in a
use-after-free warning from KASAN, e.g.:
# echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove
# echo powersave > /sys/module/pcie_aspm/parameters/policy
BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500
Call Trace:
kasan_report+0xae/0xe0
pcie_config_aspm_link+0x42d/0x500
pcie_aspm_set_policy+0x8e/0x1a0
param_attr_store+0x162/0x2c0
module_attr_store+0x3e/0x80
PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM
Control value in all functions of multi-function devices.
Disable ASPM and free the pcie_link_state when any child function is
removed so we can discard the dangling pcie_link_state->downstream pointer
and maintain the same ASPM Control configuration for all functions.
[bhelgaas: commit log and comment]
CVE-2023-53446
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix potential NULL pointer dereference
Klocwork tool reported 'cur_dsd' may be dereferenced. Add fix to validate
pointer before dereferencing the pointer.
CVE-2023-53451
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla4xxx: Add length check when parsing nlattrs
There are three places that qla4xxx parses nlattrs:
- qla4xxx_set_chap_entry()
- qla4xxx_iface_set_param()
- qla4xxx_sysfs_ddb_set_param()
and each of them directly converts the nlattr to specific pointer of
structure without length checking. This could be dangerous as those
attributes are not validated and a malformed nlattr (e.g., length 0) could
result in an OOB read that leaks heap dirty data.
Add the nla_len check before accessing the nlattr data and return EINVAL if
the length check fails.
CVE-2023-53456
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry()
This condition needs to match the previous "if (epcp->state == LISTEN) {"
exactly to avoid a NULL dereference of either "listen_ep" or "ep". The
problem is that "epcp" has been re-assigned so just testing
"if (epcp->state == LISTEN) {" a second time is not sufficient.
CVE-2023-53476
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Add lwtunnel encap size of all siblings in nexthop calculation
In function rt6_nlmsg_size(), the length of nexthop is calculated
by multipling the nexthop length of fib6_info and the number of
siblings. However if the fib6_info has no lwtunnel but the siblings
have lwtunnels, the nexthop length is less than it should be, and
it will trigger a warning in inet6_rt_notify() as follows:
WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130
......
Call Trace:
<TASK>
fib6_add_rt2node+0x685/0xa30
fib6_add+0x96/0x1b0
ip6_route_add+0x50/0xd0
inet6_rtm_newroute+0x97/0xa0
rtnetlink_rcv_msg+0x156/0x3d0
netlink_rcv_skb+0x5a/0x110
netlink_unicast+0x246/0x350
netlink_sendmsg+0x250/0x4c0
sock_sendmsg+0x66/0x70
___sys_sendmsg+0x7c/0xd0
__sys_sendmsg+0x5d/0xb0
do_syscall_64+0x3f/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
This bug can be reproduced by script:
ip -6 addr add 2002::2/64 dev ens2
ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100
for i in 10 20 30 40 50 60 70;
do
ip link add link ens2 name ipv_$i type ipvlan
ip -6 addr add 2002::$i/64 dev ipv_$i
ifconfig ipv_$i up
done
for i in 10 20 30 40 50 60;
do
ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1
dev ipv_$i metric 100
done
ip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100
This patch fixes it by adding nexthop_len of every siblings using
rt6_nh_nlmsg_size().
CVE-2023-53477
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
lib: cpu_rmap: Avoid use after free on rmap->obj array entries
When calling irq_set_affinity_notifier() with NULL at the notify
argument, it will cause freeing of the glue pointer in the
corresponding array entry but will leave the pointer in the array. A
subsequent call to free_irq_cpu_rmap() will try to free this entry again
leading to possible use after free.
Fix that by setting NULL to the array entry and checking that we have
non-zero at the array entry when iterating over the array in
free_irq_cpu_rmap().
The current code does not suffer from this since there are no cases
where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the
notify arg) is called, followed by a call to free_irq_cpu_rmap() so we
don't hit and issue. Subsequent patches in this series excersize this
flow, hence the required fix.
CVE-2023-53484
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: Fix error unwinding of XDP initialization
When initializing XDP in virtnet_open(), some rq xdp initialization
may hit an error causing net device open failed. However, previous
rqs have already initialized XDP and enabled NAPI, which is not the
expected behavior. Need to roll back the previous rq initialization
to avoid leaks in error unwinding of init code.
Also extract helper functions of disable and enable queue pairs.
Use newly introduced disable helper function in error unwinding and
virtnet_close. Use enable helper function in virtnet_open.
CVE-2023-53499
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
udf: Do not bother merging very long extents
When merging very long extents we try to push as much length as possible
to the first extent. However this is unnecessarily complicated and not
really worth the trouble. Furthermore there was a bug in the logic
resulting in corrupting extents in the file as syzbot reproducer shows.
So just don't bother with the merging of extents that are too long
together.
CVE-2023-53506
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix a memory leak
Add a forgotten kfree().
CVE-2023-53512
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
tipc: do not update mtu if msg_max is too small in mtu negotiation
When doing link mtu negotiation, a malicious peer may send Activate msg
with a very small mtu, e.g. 4 in Shuang's testing, without checking for
the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
n->links[bearer_id].mtu is set to 4294967228, which is a overflow of
'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().
With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:
tipc: Too large msg, purging xmit list 1 5 0 40 4!
tipc: Too large msg, purging xmit list 1 15 0 60 4!
And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in
named_distribute(), and when purging it in tipc_link_xmit(), a crash
was even caused:
general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19
RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0
Call Trace:
<IRQ>
skb_release_data+0xf9/0x1d0
kfree_skb_reason+0x40/0x100
tipc_link_xmit+0x57a/0x740 [tipc]
tipc_node_xmit+0x16c/0x5c0 [tipc]
tipc_named_node_up+0x27f/0x2c0 [tipc]
tipc_node_write_unlock+0x149/0x170 [tipc]
tipc_rcv+0x608/0x740 [tipc]
tipc_udp_recv+0xdc/0x1f0 [tipc]
udp_queue_rcv_one_skb+0x33e/0x620
udp_unicast_rcv_skb.isra.72+0x75/0x90
__udp4_lib_rcv+0x56d/0xc20
ip_protocol_deliver_rcu+0x100/0x2d0
This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),
and not updating mtu if it is too small.
CVE-2023-53517
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: add lock to protect parameter num_rdy
Getting below error when using KCSAN to check the driver. Adding lock to
protect parameter num_rdy when getting the value with function:
v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.
kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue
kworker/u16:3: [name:report&]
kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:
kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c
CVE-2023-53519
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]
Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013
When edev->components is zero, accessing edev->component[0] members is
wrong.
CVE-2023-53521
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
jbd2: check 'jh->b_transaction' before removing it from checkpoint
Following process will corrupt ext4 image:
Step 1:
jbd2_journal_commit_transaction
__jbd2_journal_insert_checkpoint(jh, commit_transaction)
// Put jh into trans1->t_checkpoint_list
journal->j_checkpoint_transactions = commit_transaction
// Put trans1 into journal->j_checkpoint_transactions
Step 2:
do_get_write_access
test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty
__jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2
Step 3:
drop_cache
journal_shrink_one_cp_list
jbd2_journal_try_remove_checkpoint
if (!trylock_buffer(bh)) // lock bh, true
if (buffer_dirty(bh)) // buffer is not dirty
__jbd2_journal_remove_checkpoint(jh)
// remove jh from trans1->t_checkpoint_list
Step 4:
jbd2_log_do_checkpoint
trans1 = journal->j_checkpoint_transactions
// jh is not in trans1->t_checkpoint_list
jbd2_cleanup_journal_tail(journal) // trans1 is done
Step 5: Power cut, trans2 is not committed, jh is lost in next mounting.
Fix it by checking 'jh->b_transaction' before remove it from checkpoint.
CVE-2023-53526
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()
The following call trace was observed:
localhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete
localhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092
localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"
localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]
localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1
localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022
localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]
localhost kernel: Call Trace:
localhost kernel: dump_stack_lvl+0x57/0x7d
localhost kernel: check_preemption_disabled+0xc8/0xd0
localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]
Use raw_smp_processor_id() instead of smp_processor_id().
Also use queue_work() across the driver instead of queue_work_on() thus
avoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.
CVE-2023-53530
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe
rpi_firmware_get() take reference, we need to release it in error paths
as well. Use devm_rpi_firmware_get() helper to handling the resources.
Also remove the existing rpi_firmware_put().
CVE-2023-53533
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: reject auth/assoc to AP with our address
If the AP uses our own address as its MLD address or BSSID, then
clearly something's wrong. Reject such connections so we don't
try and fail later.
CVE-2023-53540
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy
For some reason, the driver adding support for Exynos5420 MIPI phy
back in 2016 wasn't used on Exynos5420, which caused a kernel panic.
Add the proper compatible for it.
CVE-2023-53542
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb
The syzbot fuzzer identified a problem in the usbnet driver:
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Workqueue: mld mld_ifc_work
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc9000463f568 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001
RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003
R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0
Call Trace:
<TASK>
usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453
__netdev_start_xmit include/linux/netdevice.h:4918 [inline]
netdev_start_xmit include/linux/netdevice.h:4932 [inline]
xmit_one net/core/dev.c:3578 [inline]
dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594
...
This bug is caused by the fact that usbnet trusts the bulk endpoint
addresses its probe routine receives in the driver_info structure, and
it does not check to see that these endpoints actually exist and have
the expected type and directions.
The fix is simply to add such a check.
CVE-2023-53548
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iavf: Fix use-after-free in free_netdev
We do netif_napi_add() for all allocated q_vectors[], but potentially
do netif_napi_del() for part of them, then kfree q_vectors and leave
invalid pointers at dev->napi_list.
Reproducer:
[root@host ~]# cat repro.sh
#!/bin/bash
pf_dbsf="0000:41:00.0"
vf0_dbsf="0000:41:02.0"
g_pids=()
function do_set_numvf()
{
echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
sleep $((RANDOM%3+1))
echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
sleep $((RANDOM%3+1))
}
function do_set_channel()
{
local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)
[ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; }
ifconfig $nic 192.168.18.5 netmask 255.255.255.0
ifconfig $nic up
ethtool -L $nic combined 1
ethtool -L $nic combined 4
sleep $((RANDOM%3))
}
function on_exit()
{
local pid
for pid in "${g_pids[@]}"; do
kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null
done
g_pids=()
}
trap "on_exit; exit" EXIT
while :; do do_set_numvf ; done &
g_pids+=($!)
while :; do do_set_channel ; done &
g_pids+=($!)
wait
Result:
[ 4093.900222] ==================================================================
[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390
[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699
[ 4093.900233]
[ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1
[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021
[ 4093.900239] Call Trace:
[ 4093.900244] dump_stack+0x71/0xab
[ 4093.900249] print_address_description+0x6b/0x290
[ 4093.900251] ? free_netdev+0x308/0x390
[ 4093.900252] kasan_report+0x14a/0x2b0
[ 4093.900254] free_netdev+0x308/0x390
[ 4093.900261] iavf_remove+0x825/0xd20 [iavf]
[ 4093.900265] pci_device_remove+0xa8/0x1f0
[ 4093.900268] device_release_driver_internal+0x1c6/0x460
[ 4093.900271] pci_stop_bus_device+0x101/0x150
[ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20
[ 4093.900275] pci_iov_remove_virtfn+0x187/0x420
[ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10
[ 4093.900278] ? pci_get_subsys+0x90/0x90
[ 4093.900280] sriov_disable+0xed/0x3e0
[ 4093.900282] ? bus_find_device+0x12d/0x1a0
[ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e]
[ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e]
[ 4093.900299] ? pci_get_device+0x7c/0x90
[ 4093.900300] ? pci_get_subsys+0x90/0x90
[ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210
[ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10
[ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]
[ 4093.900318] sriov_numvfs_store+0x214/0x290
[ 4093.900320] ? sriov_totalvfs_show+0x30/0x30
[ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10
[ 4093.900323] ? __check_object_size+0x15a/0x350
[ 4093.900326] kernfs_fop_write+0x280/0x3f0
[ 4093.900329] vfs_write+0x145/0x440
[ 4093.900330] ksys_write+0xab/0x160
[ 4093.900332] ? __ia32_sys_read+0xb0/0xb0
[ 4093.900334] ? fput_many+0x1a/0x120
[ 4093.900335] ? filp_close+0xf0/0x130
[ 4093.900338] do_syscall_64+0xa0/0x370
[ 4093.900339] ? page_fault+0x8/0x30
[ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 4093.900357] RIP: 0033:0x7f16ad4d22c0
[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24
[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0
[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001
[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700
[ 4093.9003
---truncated---
CVE-2023-53556
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ip_vti: fix potential slab-use-after-free in decode_session6
When ip_vti device is set to the qdisc of the sfb type, the cb field
of the sent skb may be modified during enqueuing. Then,
slab-use-after-free may occur when ip_vti device sends IPv6 packets.
As commit f855691975bb ("xfrm6: Fix the nexthdr offset in
_decode_session6.") showed, xfrm_decode_session was originally intended
only for the receive path. IP6CB(skb)->nhoff is not set during
transmission. Therefore, set the cb field in the skb to 0 before
sending packets.
CVE-2023-53559
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix defrag path triggering jbd2 ASSERT
code path:
ocfs2_ioctl_move_extents
ocfs2_move_extents
ocfs2_defrag_extent
__ocfs2_move_extent
+ ocfs2_journal_access_di
+ ocfs2_split_extent //sub-paths call jbd2_journal_restart
+ ocfs2_journal_dirty //crash by jbs2 ASSERT
crash stacks:
PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2"
#0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01
#1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d
#2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d
#3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f
#4 [ffffb25d8dad3a58] do_trap at ffffffff83833205
#5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6
#6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18
[exception RIP: jbd2_journal_dirty_metadata+0x2ba]
RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207
RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250
RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000
R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28
R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]
#8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]
#9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]
Analysis
This bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call
ocfs2_journal_access_di() before ocfs2_journal_dirty() in
ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is
called by ocfs2_split_extent() during defragmenting.
How to fix
For ocfs2_split_extent() can handle journal operations totally by itself.
Caller doesn't need to call journal access/dirty pair, and caller only
needs to call journal start/stop pair. The fix method is to remove
journal access/dirty from __ocfs2_move_extent().
The discussion for this patch:
https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
CVE-2023-53564
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: don't leak memory if dev_set_name() fails
When dev_set_name() fails, zcdn_create() doesn't free the newly
allocated resources. Do it.
CVE-2023-53568
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds
Fix a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with
a CLM version string by memcpy() in brcmf_fil_iovar_data_get().
Ensure buf is null-terminated.
Found by a modified version of syzkaller.
[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22
[ 33.021554][ T1896] ==================================================================
[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110
[ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896
[ 33.023852][ T1896]
[ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132
[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event
[ 33.026581][ T1896] Call Trace:
[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d
[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334
[ 33.028037][ T1896] ? strreplace+0xf2/0x110
[ 33.028403][ T1896] ? strreplace+0xf2/0x110
[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf
[ 33.029283][ T1896] ? strreplace+0xf2/0x110
[ 33.029666][ T1896] strreplace+0xf2/0x110
[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40
[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0
[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110
[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260
[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 33.033582][ T1896] brcmf_attach+0x246/0xd40
[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50
[ 33.034383][ T1896] ? kmemdup+0x30/0x40
[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690
[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710
[ 33.036315][ T1896] really_probe+0x1be/0xa90
[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460
[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0
[ 33.037383][ T1896] driver_probe_device+0x49/0x120
[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250
[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120
[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0
[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20
[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120
[ 33.042330][ T1896] __device_attach+0x207/0x330
[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0
[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0
[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260
[ 33.043914][ T1896] device_add+0xa61/0x1ce0
[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660
[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550
[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770
[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230
[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90
[ 33.046931][ T1896] usb_probe_device+0x9c/0x220
[ 33.047434][ T1896] really_probe+0x1be/0xa90
[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460
[ 33.048134][ T1896] driver_probe_device+0x49/0x120
[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250
[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120
---truncated---
CVE-2023-53582
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Sync IRQ works before buffer destruction
If something was written to the buffer just before destruction,
it may be possible (maybe not in a real system, but it did
happen in ARCH=um with time-travel) to destroy the ringbuffer
before the IRQ work ran, leading this KASAN report (or a crash
without KASAN):
BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a
Read of size 8 at addr 000000006d640a48 by task swapper/0
CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7
Stack:
60c4f20f 0c203d48 41b58ab3 60f224fc
600477fa 60f35687 60c4f20f 601273dd
00000008 6101eb00 6101eab0 615be548
Call Trace:
[<60047a58>] show_stack+0x25e/0x282
[<60c609e0>] dump_stack_lvl+0x96/0xfd
[<60c50d4c>] print_report+0x1a7/0x5a8
[<603078d3>] kasan_report+0xc1/0xe9
[<60308950>] __asan_report_load8_noabort+0x1b/0x1d
[<60232844>] irq_work_run_list+0x11a/0x13a
[<602328b4>] irq_work_tick+0x24/0x34
[<6017f9dc>] update_process_times+0x162/0x196
[<6019f335>] tick_sched_handle+0x1a4/0x1c3
[<6019fd9e>] tick_sched_timer+0x79/0x10c
[<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695
[<60182913>] hrtimer_interrupt+0x16c/0x2c4
[<600486a3>] um_timer+0x164/0x183
[...]
Allocated by task 411:
save_stack_trace+0x99/0xb5
stack_trace_save+0x81/0x9b
kasan_save_stack+0x2d/0x54
kasan_set_track+0x34/0x3e
kasan_save_alloc_info+0x25/0x28
____kasan_kmalloc+0x8b/0x97
__kasan_kmalloc+0x10/0x12
__kmalloc+0xb2/0xe8
load_elf_phdrs+0xee/0x182
[...]
The buggy address belongs to the object at 000000006d640800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 584 bytes inside of
freed 1024-byte region [000000006d640800, 000000006d640c00)
Add the appropriate irq_work_sync() so the work finishes before
the buffers are destroyed.
Prior to the commit in the Fixes tag below, there was only a
single global IRQ work, so this issue didn't exist.
CVE-2023-53587
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't trust firmware n_channels
If the firmware sends us a corrupted MCC response with
n_channels much larger than the command response can be,
we might copy far too much (uninitialized) memory and
even crash if the n_channels is large enough to make it
run out of the one page allocated for the FW response.
Fix that by checking the lengths. Doing a < comparison
would be sufficient, but the firmware should be doing
it correctly, so check more strictly.
CVE-2023-53589
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Release folio lock on fscache read hit.
Under the current code, when cifs_readpage_worker is called, the call
contract is that the callee should unlock the page. This is documented
in the read_folio section of Documentation/filesystems/vfs.rst as:
> The filesystem should unlock the folio once the read has completed,
> whether it was successful or not.
Without this change, when fscache is in use and cache hit occurs during
a read, the page lock is leaked, producing the following stack on
subsequent reads (via mmap) to the page:
$ cat /proc/3890/task/12864/stack
[<0>] folio_wait_bit_common+0x124/0x350
[<0>] filemap_read_folio+0xad/0xf0
[<0>] filemap_fault+0x8b1/0xab0
[<0>] __do_fault+0x39/0x150
[<0>] do_fault+0x25c/0x3e0
[<0>] __handle_mm_fault+0x6ca/0xc70
[<0>] handle_mm_fault+0xe9/0x350
[<0>] do_user_addr_fault+0x225/0x6c0
[<0>] exc_page_fault+0x84/0x1b0
[<0>] asm_exc_page_fault+0x27/0x30
This requires a reboot to resolve; it is a deadlock.
Note however that the call to cifs_readpage_from_fscache does mark the
page clean, but does not free the folio lock. This happens in
__cifs_readpage_from_fscache on success. Releasing the lock at that
point however is not appropriate as cifs_readahead also calls
cifs_readpage_from_fscache and *does* unconditionally release the lock
after its return. This change therefore effectively makes
cifs_readpage_worker work like cifs_readahead.
CVE-2023-53593
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix resource leak in device_add()
When calling kobject_add() failed in device_add(), it will call
cleanup_glue_dir() to free resource. But in kobject_add(),
dev->kobj.parent has been set to NULL. This will cause resource leak.
The process is as follows:
device_add()
get_device_parent()
class_dir_create_and_add()
kobject_add() //kobject_get()
...
dev->kobj.parent = kobj;
...
kobject_add() //failed, but set dev->kobj.parent = NULL
...
glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto
//"Error" label
...
cleanup_glue_dir() //becaues glue_dir is NULL, not call
//kobject_put()
The preceding problem may cause insmod mac80211_hwsim.ko to failed.
sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'
Call Trace:
<TASK>
dump_stack_lvl+0x8e/0xd1
sysfs_warn_dup.cold+0x1c/0x29
sysfs_create_dir_ns+0x224/0x280
kobject_add_internal+0x2aa/0x880
kobject_add+0x135/0x1a0
get_device_parent+0x3d7/0x590
device_add+0x2aa/0x1cb0
device_create_groups_vargs+0x1eb/0x260
device_create+0xdc/0x110
mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]
init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]
do_one_initcall+0x10f/0x630
do_init_module+0x19f/0x5e0
load_module+0x64b7/0x6eb0
__do_sys_finit_module+0x140/0x200
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
</TASK>
kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to
register things with the same name in the same directory.
CVE-2023-53594
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers: base: Free devm resources when unregistering a device
In the current code, devres_release_all() only gets called if the device
has a bus and has been probed.
This leads to issues when using bus-less or driver-less devices where
the device might never get freed if a managed resource holds a reference
to the device. This is happening in the DRM framework for example.
We should thus call devres_release_all() in the device_del() function to
make sure that the device-managed actions are properly executed when the
device is unregistered, even if it has neither a bus nor a driver.
This is effectively the same change than commit 2f8d16a996da ("devres:
release resources on device_del()") that got reverted by commit
a525a3ddeaca ("driver core: free devres in device_release") over
memory leaks concerns.
This patch effectively combines the two commits mentioned above to
release the resources both on device_del() and device_release() and get
the best of both worlds.
CVE-2023-53596
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix mid leak during reconnection after timeout threshold
When the number of responses with status of STATUS_IO_TIMEOUT
exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect
the connection. But we do not return the mid, or the credits
returned for the mid, or reduce the number of in-flight requests.
This bug could result in the server->in_flight count to go bad,
and also cause a leak in the mids.
This change moves the check to a few lines below where the
response is decrypted, even of the response is read from the
transform header. This way, the code for returning the mids
can be reused.
Also, the cifs_reconnect was reconnecting just the transport
connection before. In case of multi-channel, this may not be
what we want to do after several timeouts. Changed that to
reconnect the session and the tree too.
Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name
MAX_STATUS_IO_TIMEOUT.
CVE-2023-53597
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Avoid fcport pointer dereference
Klocwork reported warning of NULL pointer may be dereferenced. The routine
exits when sa_ctl is NULL and fcport is allocated after the exit call thus
causing NULL fcport pointer to dereference at the time of exit.
To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.
CVE-2023-53603
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm integrity: call kmem_cache_destroy() in dm_integrity_init() error path
Otherwise the journal_io_cache will leak if dm_register_target() fails.
CVE-2023-53604
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipmi_si: fix a memleak in try_smi_init()
Kmemleak reported the following leak info in try_smi_init():
unreferenced object 0xffff00018ecf9400 (size 1024):
comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)
backtrace:
[<000000004ca5b312>] __kmalloc+0x4b8/0x7b0
[<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si]
[<000000006460d325>] 0xffff800081b10148
[<0000000039206ea5>] do_one_initcall+0x64/0x2a4
[<00000000601399ce>] do_init_module+0x50/0x300
[<000000003c12ba3c>] load_module+0x7a8/0x9e0
[<00000000c246fffe>] __se_sys_init_module+0x104/0x180
[<00000000eea99093>] __arm64_sys_init_module+0x24/0x30
[<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250
[<0000000070f4f8b7>] do_el0_svc+0x48/0xe0
[<000000005a05337f>] el0_svc+0x24/0x3c
[<000000005eb248d6>] el0_sync_handler+0x160/0x164
[<0000000030a59039>] el0_sync+0x160/0x180
The problem was that when an error occurred before handlers registration
and after allocating `new_smi->si_sm`, the variable wouldn't be freed in
the error handling afterwards since `shutdown_smi()` hadn't been
registered yet. Fix it by adding a `kfree()` in the error handling path
in `try_smi_init()`.
CVE-2023-53611
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix deletion race condition
System crash when using debug kernel due to link list corruption. The cause
of the link list corruption is due to session deletion was allowed to queue
up twice. Here's the internal trace that show the same port was allowed to
double queue for deletion on different cpu.
20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1
20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1
Move the clearing/setting of deleted flag lock.
CVE-2023-53615
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: Avoid nf_ct_helper_hash uses after free
If nf_conntrack_init_start() fails (for example due to a
register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()
clean-up path frees the nf_ct_helper_hash map.
When built with NF_CONNTRACK=y, further netfilter modules (e.g:
netfilter_conntrack_ftp) can still be loaded and call
nf_conntrack_helpers_register(), independently of whether nf_conntrack
initialized correctly. This accesses the nf_ct_helper_hash dangling
pointer and causes a uaf, possibly leading to random memory corruption.
This patch guards nf_conntrack_helper_register() from accessing a freed
or uninitialized nf_ct_helper_hash pointer and fixes possible
uses-after-free when loading a conntrack module.
CVE-2023-53619
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md: fix soft lockup in status_resync
status_resync() will calculate 'curr_resync - recovery_active' to show
user a progress bar like following:
[============>........] resync = 61.4%
'curr_resync' and 'recovery_active' is updated in md_do_sync(), and
status_resync() can read them concurrently, hence it's possible that
'curr_resync - recovery_active' can overflow to a huge number. In this
case status_resync() will be stuck in the loop to print a large amount
of '=', which will end up soft lockup.
Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,
this way resync in progress will be reported to user.
CVE-2023-53620
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix possible data races in gfs2_show_options()
Some fields such as gt_logd_secs of the struct gfs2_tune are accessed
without holding the lock gt_spin in gfs2_show_options():
val = sdp->sd_tune.gt_logd_secs;
if (val != 30)
seq_printf(s, ",commit=%d", val);
And thus can cause data races when gfs2_show_options() and other functions
such as gfs2_reconfigure() are concurrently executed:
spin_lock(>->gt_spin);
gt->gt_logd_secs = newargs->ar_commit;
To fix these possible data races, the lock sdp->sd_tune.gt_spin is
acquired before accessing the fields of gfs2_tune and released after these
accesses.
Further changes by Andreas:
- Don't hold the spin lock over the seq_printf operations.
CVE-2023-53622
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_fq: fix integer overflow of "credit"
if sch_fq is configured with "initial quantum" having values greater than
INT_MAX, the first assignment of "credit" does signed integer overflow to
a very negative value.
In this situation, the syzkaller script provided by Cristoph triggers the
CPU soft-lockup warning even with few sockets. It's not an infinite loop,
but "credit" wasn't probably meant to be minus 2Gb for each new flow.
Capping "initial quantum" to INT_MAX proved to fix the issue.
v2: validation of "initial quantum" is done in fq_policy, instead of open
coding in fq_change() _ suggested by Jakub Kicinski
CVE-2023-53624
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: fix wrong ct->timeout value
(struct nf_conn)->timeout is an interval before the conntrack
confirmed. After confirmed, it becomes a timestamp.
It is observed that timeout of an unconfirmed conntrack:
- Set by calling ctnetlink_change_timeout(). As a result,
`nfct_time_stamp` was wrongly added to `ct->timeout` twice.
- Get by calling ctnetlink_dump_timeout(). As a result,
`nfct_time_stamp` was wrongly subtracted.
Call Trace:
<TASK>
dump_stack_lvl
ctnetlink_dump_timeout
__ctnetlink_glue_build
ctnetlink_glue_build
__nfqnl_enqueue_packet
nf_queue
nf_hook_slow
ip_mc_output
? __pfx_ip_finish_output
ip_send_skb
? __pfx_dst_output
udp_send_skb
udp_sendmsg
? __pfx_ip_generic_getfrag
sock_sendmsg
Separate the 2 cases in:
- Setting `ct->timeout` in __nf_ct_set_timeout().
- Getting `ct->timeout` in ctnetlink_dump_timeout().
Pablo appends:
Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag is
set on, otherwise conntrack creation via ctnetlink breaks.
Note that the problem described in this patch occurs since the
introduction of the nfnetlink_queue conntrack support, select a
sufficiently old Fixes: tag for -stable kernel to pick up this fix.
CVE-2023-53635
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: hif_usb: fix memory leak of remain_skbs
hif_dev->remain_skb is allocated and used exclusively in
ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is
processed and subsequently freed (in error paths) only during the next
call of ath9k_hif_usb_rx_stream().
So, if the urbs are deallocated between those two calls due to the device
deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()
is not called next time and the allocated remain_skb is leaked. Our local
Syzkaller instance was able to trigger that.
remain_skb makes sense when receiving two consecutive urbs which are
logically linked together, i.e. a specific data field from the first skb
indicates a cached skb to be allocated, memcpy'd with some data and
subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs
deallocation supposedly makes that link irrelevant so we need to free the
cached skb in those cases.
Fix the leak by introducing a function to explicitly free remain_skb (if
it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL
when it has not been allocated at all (hif_dev struct is kzalloced) or
when it has been processed in next call to ath9k_hif_usb_rx_stream().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2023-53641
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: radio-shark: Add endpoint checks
The syzbot fuzzer was able to provoke a WARNING from the radio-shark2
driver:
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac
RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387
shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88
...
The problem was caused by the fact that the driver does not check
whether the endpoints it uses are actually present and have the
appropriate types. This can be fixed by adding a simple check of
these endpoints (and similarly for the radio-shark driver).
CVE-2023-53644
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Don't dereference ACPI root object handle
Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.
However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).
This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.
I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.
Fix this by explicitly terminating the lookup at the ACPI namespace root
object.
Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.
Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0
[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200
[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0
[ 3.723559] ? down_timeout+0x3a/0x60
[ 3.724455] ? acpi_ns_get_node+0x3a/0x60
[ 3.725412] acpi_ns_get_node+0x3a/0x60
[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0
[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0
[ 3.728400] acpi_rs_get_method_data+0x2b/0x70
[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.732411] acpi_walk_resources+0x78/0xd0
[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]
[ 3.734802] platform_probe+0x3d/0x90
[ 3.735684] really_probe+0x19b/0x400
[ 3.736570] ? __device_attach_driver+0x100/0x100
[ 3.737697] __driver_probe_device+0x78/0x160
[ 3.738746] driver_probe_device+0x1f/0x90
[ 3.739743] __driver_attach+0xc2/0x1b0
[ 3.740671] bus_for_each_dev+0x70/0xc0
[ 3.741601] bus_add_driver+0x10e/0x210
[ 3.742527] driver_register+0x55/0xf0
[ 3.744412] ? 0xffffffffc039a000
[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
CVE-2023-53647
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer
smatch error:
sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:
we previously assumed 'rac97' could be null (see line 2072)
remove redundant assignment, return error if rac97 is NULL.
CVE-2023-53648
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()
If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
CVE-2023-53650
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize
Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than
the calculated "min" value, but greater than zero, the logic sets
tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in
cdc_ncm_fill_tx_frame() where all the data is handled.
For small values of dwNtbOutMaxSize the memory allocated during
alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to
how size is aligned at alloc time:
size = SKB_DATA_ALIGN(size);
size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
Thus we hit the same bug that we tried to squash with
commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")
Low values of dwNtbOutMaxSize do not cause an issue presently because at
alloc_skb() time more memory (512b) is allocated than required for the
SKB headers alone (320b), leaving some space (512b - 320b = 192b)
for CDC data (172b).
However, if more elements (for example 3 x u64 = [24b]) were added to
one of the SKB header structs, say 'struct skb_shared_info',
increasing its original size (320b [320b aligned]) to something larger
(344b [384b aligned]), then suddenly the CDC data (172b) no longer
fits in the spare SKB data area (512b - 384b = 128b).
Consequently the SKB bounds checking semantics fails and panics:
skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:113!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
Workqueue: mld mld_ifc_work
RIP: 0010:skb_panic net/core/skbuff.c:113 [inline]
RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118
[snip]
Call Trace:
<TASK>
skb_put+0x151/0x210 net/core/skbuff.c:2047
skb_put_zero include/linux/skbuff.h:2422 [inline]
cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]
cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308
cdc_ncm_tx_fixup+0xa3/0x100
Deal with too low values of dwNtbOutMaxSize, clamp it in the range
[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure
enough data space is allocated to handle CDC data by making sure
dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.
CVE-2023-53667
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix deadloop issue on reading trace_pipe
Soft lockup occurs when reading file 'trace_pipe':
watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
[...]
RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb
RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218
RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f
R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901
R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000
[...]
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__find_next_entry+0x1a8/0x4b0
? peek_next_entry+0x250/0x250
? down_write+0xa5/0x120
? down_write_killable+0x130/0x130
trace_find_next_entry_inc+0x3b/0x1d0
tracing_read_pipe+0x423/0xae0
? tracing_splice_read_pipe+0xcb0/0xcb0
vfs_read+0x16b/0x490
ksys_read+0x105/0x210
? __ia32_sys_pwrite64+0x200/0x200
? switch_fpu_return+0x108/0x220
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x61/0xc6
Through the vmcore, I found it's because in tracing_read_pipe(),
ring_buffer_empty_cpu() found some buffer is not empty but then it
cannot read anything due to "rb_num_of_entries() == 0" always true,
Then it infinitely loop the procedure due to user buffer not been
filled, see following code path:
tracing_read_pipe() {
... ...
waitagain:
tracing_wait_pipe() // 1. find non-empty buffer here
trace_find_next_entry_inc() // 2. loop here try to find an entry
__find_next_entry()
ring_buffer_empty_cpu(); // 3. find non-empty buffer
peek_next_entry() // 4. but peek always return NULL
ring_buffer_peek()
rb_buffer_peek()
rb_get_reader_page()
// 5. because rb_num_of_entries() == 0 always true here
// then return NULL
// 6. user buffer not been filled so goto 'waitgain'
// and eventually leads to an deadloop in kernel!!!
}
By some analyzing, I found that when resetting ringbuffer, the 'entries'
of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which
cause wrong 'overrun' count and eventually cause the deadloop issue.
To fix it, we need to clear every pages in rb_reset_cpu().
CVE-2023-53668
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: output extra debug info if we failed to find an inline backref
[BUG]
Syzbot reported several warning triggered inside
lookup_inline_extent_backref().
[CAUSE]
As usual, the reproducer doesn't reliably trigger locally here, but at
least we know the WARN_ON() is triggered when an inline backref can not
be found, and it can only be triggered when @insert is true. (I.e.
inserting a new inline backref, which means the backref should already
exist)
[ENHANCEMENT]
After the WARN_ON(), dump all the parameters and the extent tree
leaf to help debug.
CVE-2023-53672
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix possible desc_ptr out-of-bounds accesses
Sanitize possible desc_ptr out-of-bounds accesses in
ses_enclosure_data_process().
CVE-2023-53675
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()
The function lio_target_nacl_info_show() uses sprintf() in a loop to print
details for every iSCSI connection in a session without checking for the
buffer length. With enough iSCSI connections it's possible to overflow the
buffer provided by configfs and corrupt the memory.
This patch replaces sprintf() with sysfs_emit_at() that checks for buffer
boundries.
CVE-2023-53676
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent
In some specific situations, the return value of __bch_btree_node_alloc
may be NULL. This may lead to a potential NULL pointer dereference in
caller function like a calling chain :
btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.
Fix it by initializing the return value in __bch_btree_node_alloc.
CVE-2023-53681
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()
syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), for
crafted filesystem image can contain bogus length. There conditions are
not kernel bugs that can justify kernel to panic.
CVE-2023-53683
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk
When the best clk is searched, we iterate over all possible clk.
If we find a better match, the previous one, if any, needs to be freed.
If a better match has already been found, we still need to free the new
one, otherwise it leaks.
CVE-2023-53687
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
udf: Detect system inodes linked into directory hierarchy
When UDF filesystem is corrupted, hidden system inodes can be linked
into directory hierarchy which is an avenue for further serious
corruption of the filesystem and kernel confusion as noticed by syzbot
fuzzed images. Refuse to access system inodes linked into directory
hierarchy and vice versa.
CVE-2023-53695
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()
There is a memory leak reported by kmemleak:
unreferenced object 0xffffc900003f0000 (size 12288):
comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110
[<0000000001906886>] __vmalloc_node+0xbd/0x150
[<000000005bb4dc34>] vmalloc+0x25/0x30
[<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]
[<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]
[<00000000641ccc04>] local_pci_probe+0xeb/0x1a0
The root cause is traced to an error-handling path in qla2x00_probe_one()
when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is
used to record the port information and it is allocated in
qla2x00_create_host(). However, it is not released in the error handling
path "probe_failed".
Fix this by freeing the memory of "scan.l" when an error occurs in the
adapter initialization process.
CVE-2023-53696
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix out-of-bounds access in ipv6_find_tlv()
optlen is fetched without checking whether there is more than one byte to parse.
It can lead to out-of-bounds access.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.
CVE-2023-53705
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1
The type of size is unsigned int, if size is 0x40000000, there will
be an integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later.
CVE-2023-53707
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex
Apparently the hex passphrase mechanism does not work on newer
chips/firmware (e.g. BCM4387). It seems there was a simple way of
passing it in binary all along, so use that and avoid the hexification.
OpenBSD has been doing it like this from the beginning, so this should
work on all chips.
Also clear the structure before setting the PMK. This was leaking
uninitialized stack contents to the device.
CVE-2023-53715
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()
Fix a stack-out-of-bounds write that occurs in a WMI response callback
function that is called after a timeout occurs in ath9k_wmi_cmd().
The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer that
could no longer be valid when a timeout occurs. Set wmi->last_seq_id to
0 when a timeout occurred.
Found by a modified version of syzkaller.
BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx
Write of size 4
Call Trace:
memcpy
ath9k_wmi_ctrl_rx
ath9k_htc_rx_msg
ath9k_hif_usb_reg_in_cb
__usb_hcd_giveback_urb
usb_hcd_giveback_urb
dummy_timer
call_timer_fn
run_timer_softirq
__do_softirq
irq_exit_rcu
sysvec_apic_timer_interrupt
CVE-2023-53717
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
md: raid1: fix potential OOB in raid1_remove_disk()
If rddev->raid_disk is greater than mddev->raid_disks, there will be
an out-of-bounds in raid1_remove_disk(). We have already found
similar reports as follows:
1) commit d17f744e883b ("md-raid10: fix KASAN warning")
2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")
Fix this bug by checking whether the "number" variable is
valid.
CVE-2023-53722
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knode
When u32_replace_hw_knode fails, we need to undo the tcf_bind_filter
operation done at u32_set_parms.
CVE-2023-53733
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
NSS was susceptible to a timing side-channel attack when performing RSA decryption. This attack could potentially allow an attacker to recover the private data. This vulnerability affects Firefox < 124, Firefox ESR < 115.9, and Thunderbird < 115.9.
CVE-2023-5388
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:mozilla-nss-certs-3.112.2-58.133.1
moderate
NULL Pointer Dereference in GitHub repository vim/vim prior to 20d161ace307e28690229b68584f2d84556f8960.
CVE-2023-5441
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
Use After Free in GitHub repository vim/vim prior to v9.0.2010.
CVE-2023-5535
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
important
Issue summary: Generating excessively long X9.42 DH keys or checking
excessively long X9.42 DH keys or parameters may be very slow.
Impact summary: Applications that use the functions DH_generate_key() to
generate an X9.42 DH key may experience long delays. Likewise, applications
that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()
to check an X9.42 DH key or X9.42 DH parameters may experience long delays.
Where the key or parameters that are being checked have been obtained from
an untrusted source this may lead to a Denial of Service.
While DH_check() performs all the necessary checks (as of CVE-2023-3817),
DH_check_pub_key() doesn't make any of these checks, and is therefore
vulnerable for excessively large P and Q parameters.
Likewise, while DH_generate_key() performs a check for an excessively large
P, it doesn't check for an excessively large Q.
An application that calls DH_generate_key() or DH_check_pub_key() and
supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
DH_generate_key() and DH_check_pub_key() are also called by a number of
other OpenSSL functions. An application calling any of those other
functions may similarly be affected. The other functions affected by this
are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().
Also vulnerable are the OpenSSL pkey command line application when using the
"-pubcheck" option, as well as the OpenSSL genpkey command line application.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2023-5678
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_0_0-1.0.2p-3.98.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:openssl-1_0_0-1.0.2p-3.98.1
moderate
A heap out-of-bounds write vulnerability in the Linux kernel's Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation.
If perf_read_group() is called while an event's sibling_list is smaller than its child's sibling_list, it can increment or write to memory locations outside of the allocated buffer.
We recommend upgrading past commit 32671e3799ca2e4590773fd0e63aaa4229e50c06.
CVE-2023-5717
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A flaw was found in libssh. By utilizing the ProxyCommand or ProxyJump feature, users can exploit unchecked hostname syntax on the client. This issue may allow an attacker to inject malicious code into the command of the features mentioned through the hostname parameter.
CVE-2023-6004
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access.
CVE-2023-6040
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An out-of-bounds read vulnerability was found in the NVMe-oF/TCP subsystem in the Linux kernel. This issue may allow a remote attacker to send a crafted TCP packet, triggering a heap-based buffer overflow that results in kmalloc data being printed and potentially leaked to the kernel ring buffer (dmesg).
CVE-2023-6121
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.
CVE-2023-6270
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.
CVE-2023-6356
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.
CVE-2023-6535
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.
CVE-2023-6536
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was found in the CPython `tempfile.TemporaryDirectory` class affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.
The tempfile.TemporaryDirectory class would dereference symlinks during cleanup of permissions-related errors. This means users which can run privileged programs are potentially able to modify permissions of files referenced by symlinks in some circumstances.
CVE-2023-6597
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
An out-of-bounds read vulnerability was found in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.
CVE-2023-6606
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An out-of-bounds read vulnerability was found in smb2_dump_detail in fs/smb/client/smb2ops.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.
CVE-2023-6610
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in the libssh implements abstract layer for message digest (MD) operations implemented by different supported crypto backends. The return values from these were not properly checked, which could cause low-memory situations failures, NULL dereferences, crashes, or usage of the uninitialized memory as an input for the KDF. In this case, non-matching keys will result in decryption/integrity failures, terminating the connection.
CVE-2023-6918
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
A heap out-of-bounds write vulnerability in the Linux kernel's Performance Events system component can be exploited to achieve local privilege escalation.
A perf_event's read_size can overflow, leading to an heap out-of-bounds increment or write in perf_read_group().
We recommend upgrading past commit 382c27f4ed28f803b1f1473ac2d8db0afc795a1b.
CVE-2023-6931
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A use-after-free vulnerability in the Linux kernel's ipv4: igmp component can be exploited to achieve local privilege escalation.
A race condition can be exploited to cause a timer be mistakenly registered on a RCU read locked object which is freed by another thread.
We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1.
CVE-2023-6932
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.
CVE-2023-7042
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.
CVE-2023-7192
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Debian's cpio contains a path traversal vulnerability. This issue was introduced by reverting CVE-2015-1197 patches which had caused a regression in --no-absolute-filenames. Upstream has since provided a proper fix to --no-absolute-filenames.
CVE-2023-7207
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:cpio-2.11-36.21.1
moderate
In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.
CVE-2023-7256
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpcap1-1.8.1-10.9.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix possible addl_desc_ptr out-of-bounds accesses
Sanitize possible addl_desc_ptr out-of-bounds accesses in
ses_enclosure_data_process().
CVE-2023-7324
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.
CVE-2024-0340
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
A defect was discovered in the Python “ssl” module where there is a memory
race condition with the ssl.SSLContext methods “cert_store_stats()” and
“get_ca_certs()”. The race condition can be triggered if the methods are
called at the same time as certificates are loaded into the SSLContext,
such as during the TLS handshake with a certificate directory configured.
This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.
CVE-2024-0397
moderate
An issue was found in the CPython `zipfile` module affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.
The zipfile module is vulnerable to “quoted-overlap” zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.
CVE-2024-0450
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.
CVE-2024-0607
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel's SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
CVE-2024-0639
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL
to crash leading to a potential Denial of Service attack
Impact summary: Applications loading files in the PKCS12 format from untrusted
sources might terminate abruptly.
A file in PKCS12 format can contain certificates and keys and may come from an
untrusted source. The PKCS12 specification allows certain fields to be NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL pointer
dereference that results in OpenSSL crashing. If an application processes PKCS12
files from an untrusted source using the OpenSSL APIs then that application will
be vulnerable to this issue.
OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().
We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.
CVE-2024-0727
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_0_0-1.0.2p-3.98.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:openssl-1_0_0-1.0.2p-3.98.1
low
A use-after-free flaw was found in the __ext4_remount in fs/ext4/super.c in ext4 in the Linux kernel. This flaw allows a local user to cause an information leak problem while freeing the old quota file names before a potential failure, leading to a use-after-free.
CVE-2024-0775
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.
CVE-2024-10041
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libapparmor1-2.8.2-56.26.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:pam-1.1.8-24.77.1
moderate
Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.
CVE-2024-10524
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:wget-1.14-21.25.1
moderate
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT.
We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
CVE-2024-1086
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
When asked to both use a `.netrc` file for credentials and to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.
This flaw only manifests itself if the netrc file has an entry that matches
the redirect target hostname but the entry either omits just the password or
omits both login and password.
CVE-2024-11053
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
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-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.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-v20260125-x86-64:bind-utils-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libbind9-161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libdns1110-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libirs161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisc1107-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccc161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccfg163-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:liblwres161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-bind-9.11.22-3.65.1
important
A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues.
CVE-2024-1151
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:rsync-3.1.3-3.34.1
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-v20260125-x86-64:rsync-3.1.3-3.34.1
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-v20260125-x86-64:rsync-3.1.3-3.34.1
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-v20260125-x86-64:rsync-3.1.3-3.34.1
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-v20260125-x86-64:libtasn1-4.9-3.19.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libtasn1-6-4.9-3.19.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-v20260125-x86-64:libgnutls30-3.4.17-8.20.1
moderate
Allows modifying some file metadata (e.g. last modified) with filter="data" or file permissions (chmod) with filter="tar" of files outside the extraction directory.
You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.
Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.
Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
CVE-2024-12718
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-v20260125-x86-64:rsync-3.1.3-3.34.1
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-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
moderate
Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name.
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.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.
CVE-2024-1737
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:bind-utils-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libbind9-161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libdns1110-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libirs161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisc1107-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccc161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccfg163-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:liblwres161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-bind-9.11.22-3.65.1
important
If a server hosts a zone containing a "KEY" Resource Record, or a resolver DNSSEC-validates a "KEY" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.
This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.
CVE-2024-1975
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:bind-utils-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libbind9-161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libdns1110-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libirs161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisc1107-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccc161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccfg163-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:liblwres161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-bind-9.11.22-3.65.1
important
When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled. curl --proto -all,-http http://curl.se The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.
CVE-2024-2004
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
CVE-2024-2201
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.
This issue affects Linux kernel: v2.6.12-rc2.
CVE-2024-22099
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts.
CVE-2024-2236
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgcrypt20-1.6.1-16.86.1
moderate
Vim before 9.0.2142 has a stack-based buffer overflow because did_set_langmap in map.c calls sprintf to write to the error buffer that is passed down to the option callback functions.
CVE-2024-22667
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
important
Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.
CVE-2024-23307
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.
CVE-2024-23848
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.
CVE-2024-23849
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl.
CVE-2024-23851
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory. Further, this error condition fails silently and is therefore not easily detected by an application.
CVE-2024-2398
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.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
A race condition was found in the Linux kernel's scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
CVE-2024-24855
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
CVE-2024-24861
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.
CVE-2024-25062
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
important
Issue summary: Some non-default TLS server configurations can cause unbounded
memory growth when processing TLSv1.3 sessions
Impact summary: An attacker may exploit certain server configurations to trigger
unbounded memory growth that would lead to a Denial of Service
This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is
being used (but not if early_data support is also configured and the default
anti-replay protection is in use). In this case, under certain conditions, the
session cache can get into an incorrect state and it will fail to flush properly
as it fills. The session cache will continue to grow in an unbounded manner. A
malicious client could deliberately create the scenario for this failure to
force a Denial of Service. It may also happen by accident in normal operation.
This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS
clients.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
1.0.2 is also not affected by this issue.
CVE-2024-2511
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
moderate
Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c.
CVE-2024-26458
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
important
Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.
CVE-2024-26461
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tls: fix race between tx work scheduling and socket close
Similarly to previous commit, the submitting thread (recvmsg/sendmsg)
may exit as soon as the async crypto handler calls complete().
Reorder scheduling the work before calling complete().
This seems more logical in the first place, as it's
the inverse order of what the submitting thread will do.
CVE-2024-26585
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix stack corruption
When tc filters are first added to a net device, the corresponding local
port gets bound to an ACL group in the device. The group contains a list
of ACLs. In turn, each ACL points to a different TCAM region where the
filters are stored. During forwarding, the ACLs are sequentially
evaluated until a match is found.
One reason to place filters in different regions is when they are added
with decreasing priorities and in an alternating order so that two
consecutive filters can never fit in the same region because of their
key usage.
In Spectrum-2 and newer ASICs the firmware started to report that the
maximum number of ACLs in a group is more than 16, but the layout of the
register that configures ACL groups (PAGT) was not updated to account
for that. It is therefore possible to hit stack corruption [1] in the
rare case where more than 16 ACLs in a group are required.
Fix by limiting the maximum ACL group size to the minimum between what
the firmware reports and the maximum ACLs that fit in the PAGT register.
Add a test case to make sure the machine does not crash when this
condition is hit.
[1]
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
[...]
dump_stack_lvl+0x36/0x50
panic+0x305/0x330
__stack_chk_fail+0x15/0x20
mlxsw_sp_acl_tcam_group_update+0x116/0x120
mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
mlxsw_sp_acl_rule_add+0x47/0x240
mlxsw_sp_flower_replace+0x1a9/0x1d0
tc_setup_cb_add+0xdc/0x1c0
fl_hw_replace_filter+0x146/0x1f0
fl_change+0xc17/0x1360
tc_new_tfilter+0x472/0xb90
rtnetlink_rcv_msg+0x313/0x3b0
netlink_rcv_skb+0x58/0x100
netlink_unicast+0x244/0x390
netlink_sendmsg+0x1e4/0x440
____sys_sendmsg+0x164/0x260
___sys_sendmsg+0x9a/0xe0
__sys_sendmsg+0x7a/0xc0
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVE-2024-26586
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
failing to attach the region to an ACL group, we hit a NULL pointer
dereference upon 'region->group->tcam' [1].
Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0
[...]
Call Trace:
mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20
mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
mlxsw_sp_acl_rule_add+0x47/0x240
mlxsw_sp_flower_replace+0x1a9/0x1d0
tc_setup_cb_add+0xdc/0x1c0
fl_hw_replace_filter+0x146/0x1f0
fl_change+0xc17/0x1360
tc_new_tfilter+0x472/0xb90
rtnetlink_rcv_msg+0x313/0x3b0
netlink_rcv_skb+0x58/0x100
netlink_unicast+0x244/0x390
netlink_sendmsg+0x1e4/0x440
____sys_sendmsg+0x164/0x260
___sys_sendmsg+0x9a/0xe0
__sys_sendmsg+0x7a/0xc0
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVE-2024-26595
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
If the external phy working together with phy-omap-usb2 does not implement
send_srp(), we may still attempt to call it. This can happen on an idle
Ethernet gadget triggering a wakeup for example:
configfs-gadget.g1 gadget.0: ECM Suspend
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at 0x0
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268
arp_solicit from neigh_probe+0x54/0x7c
neigh_probe from __neigh_event_send+0x22c/0x47c
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
ip_finish_output2 from ip_send_skb+0x40/0xd8
ip_send_skb from udp_send_skb+0x124/0x340
udp_send_skb from udp_sendmsg+0x780/0x984
udp_sendmsg from __sys_sendto+0xd8/0x158
__sys_sendto from ret_fast_syscall+0x0/0x58
Let's fix the issue by checking for send_srp() and set_vbus() before
calling them. For USB peripheral only cases these both could be NULL.
CVE-2024-26600
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: make sure init the accept_queue's spinlocks once
When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
<IRQ>
_raw_spin_unlock (kernel/locking/spinlock.c:186)
inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
tcp_check_req (net/ipv4/tcp_minisocks.c:868)
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
ip_local_deliver_finish (net/ipv4/ip_input.c:234)
__netif_receive_skb_one_core (net/core/dev.c:5529)
process_backlog (./include/linux/rcupdate.h:779)
__napi_poll (net/core/dev.c:6533)
net_rx_action (net/core/dev.c:6604)
__do_softirq (./arch/x86/include/asm/jump_label.h:27)
do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
</IRQ>
<TASK>
__local_bh_enable_ip (kernel/softirq.c:381)
__dev_queue_xmit (net/core/dev.c:4374)
ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
__ip_queue_xmit (net/ipv4/ip_output.c:535)
__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
release_sock (net/core/sock.c:3536)
inet_wait_for_connect (net/ipv4/af_inet.c:609)
__inet_stream_connect (net/ipv4/af_inet.c:702)
inet_stream_connect (net/ipv4/af_inet.c:748)
__sys_connect (./include/linux/file.h:45 net/socket.c:2064)
__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
RIP: 0033:0x7fa10ff05a3d
Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89
c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
</TASK>
The issue triggering process is analyzed as follows:
Thread A Thread B
tcp_v4_rcv //receive ack TCP packet inet_shutdown
tcp_check_req tcp_disconnect //disconnect sock
... tcp_set_state(sk, TCP_CLOSE)
inet_csk_complete_hashdance ...
inet_csk_reqsk_queue_add
---truncated---
CVE-2024-26614
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>
- continuously dump SMC-D connections in parallel:
watch -n 1 'smcss -D'
BUG: kernel NULL pointer dereference, address: 0000000000000030
CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55
RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
Call Trace:
<TASK>
? __die+0x24/0x70
? page_fault_oops+0x66/0x150
? exc_page_fault+0x69/0x140
? asm_exc_page_fault+0x26/0x30
? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
? __kmalloc_node_track_caller+0x35d/0x430
? __alloc_skb+0x77/0x170
smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
smc_diag_dump+0x26/0x60 [smc_diag]
netlink_dump+0x19f/0x320
__netlink_dump_start+0x1dc/0x300
smc_diag_handler_dump+0x6a/0x80 [smc_diag]
? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
sock_diag_rcv_msg+0x121/0x140
? __pfx_sock_diag_rcv_msg+0x10/0x10
netlink_rcv_skb+0x5a/0x110
sock_diag_rcv+0x28/0x40
netlink_unicast+0x22a/0x330
netlink_sendmsg+0x1f8/0x420
__sock_sendmsg+0xb0/0xc0
____sys_sendmsg+0x24e/0x300
? copy_msghdr_from_user+0x62/0x80
___sys_sendmsg+0x7c/0xd0
? __do_fault+0x34/0x160
? do_read_fault+0x5f/0x100
? do_fault+0xb0/0x110
? __handle_mm_fault+0x2b0/0x6c0
__sys_sendmsg+0x4d/0x80
do_syscall_64+0x69/0x180
entry_SYSCALL_64_after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn->rmb_desc. So fix it by checking before dump.
CVE-2024-26615
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tomoyo: fix UAF write bug in tomoyo_write_control()
Since tomoyo_write_control() updates head->write_buf when write()
of long lines is requested, we need to fetch head->write_buf after
head->io_sem is held. Otherwise, concurrent write() requests can
cause use-after-free-write and double-free problems.
CVE-2024-26622
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
llc: call sock_orphan() at release time
syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
pointer in a closed llc socket.
In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
calling proto_ops::release()") Eric Biggers hinted that some protocols
are missing a sock_orphan(), we need to perform a full audit.
In net-next, I plan to clear sock->sk from sock_orphan() and
amend Eric patch to add a warning.
[1]
BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:488
kasan_report+0xda/0x110 mm/kasan/report.c:601
list_empty include/linux/list.h:373 [inline]
waitqueue_active include/linux/wait.h:127 [inline]
sock_def_write_space_wfree net/core/sock.c:3384 [inline]
sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
skb_release_all net/core/skbuff.c:1092 [inline]
napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
__napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
napi_poll net/core/dev.c:6645 [inline]
net_rx_action+0x956/0xe90 net/core/dev.c:6778
__do_softirq+0x21a/0x8de kernel/softirq.c:553
run_ksoftirqd kernel/softirq.c:921 [inline]
run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
kthread+0x2c6/0x3a0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
</TASK>
Allocated by task 5167:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:314 [inline]
__kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3813 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879
alloc_inode_sb include/linux/fs.h:3019 [inline]
sock_alloc_inode+0x25/0x1c0 net/socket.c:308
alloc_inode+0x5d/0x220 fs/inode.c:260
new_inode_pseudo+0x16/0x80 fs/inode.c:1005
sock_alloc+0x40/0x270 net/socket.c:634
__sock_create+0xbc/0x800 net/socket.c:1535
sock_create net/socket.c:1622 [inline]
__sys_socket_create net/socket.c:1659 [inline]
__sys_socket+0x14c/0x260 net/socket.c:1706
__do_sys_socket net/socket.c:1720 [inline]
__se_sys_socket net/socket.c:1718 [inline]
__x64_sys_socket+0x72/0xb0 net/socket.c:1718
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Freed by task 0:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inlin
---truncated---
CVE-2024-26625
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
Reading frag_off can only be done if we pulled enough bytes
to skb->head. Currently we might access garbage.
[1]
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
pskb_may_pull include/linux/skbuff.h:2681 [inline]
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendms
---truncated---
CVE-2024-26633
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
llc: Drop support for ETH_P_TR_802_2.
syzbot reported an uninit-value bug below. [0]
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().
However, the initialisation is done only when skb->protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.
The missing initialisation existed prior to commit 211ed865108e
("net: delete all instances of special processing for token ring").
It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
Let's remove llc_tr_packet_type and complete the deprecation.
[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
__llc_lookup_established+0xe9d/0xf90
__llc_lookup net/llc/llc_conn.c:611 [inline]
llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
__netif_receive_skb_one_core net/core/dev.c:5527 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
netif_receive_skb_internal net/core/dev.c:5727 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5786
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2020 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x8ef/0x1490 fs/read_write.c:584
ksys_write+0x20f/0x4c0 fs/read_write.c:637
__do_sys_write fs/read_write.c:649 [inline]
__se_sys_write fs/read_write.c:646 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Local variable daddr created at:
llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
CVE-2024-26635
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
llc: make llc_ui_sendmsg() more robust against bonding changes
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
Like some others, llc_ui_sendmsg() releases the socket lock before
calling sock_alloc_send_skb().
Then it acquires it again, but does not redo all the sanity checks
that were performed.
This fix:
- Uses LL_RESERVED_SPACE() to reserve space.
- Check all conditions again after socket lock is held again.
- Do not account Ethernet header for mtu limitation.
[1]
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
kernel BUG at net/core/skbuff.c:193 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_panic net/core/skbuff.c:189 [inline]
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
lr : skb_panic net/core/skbuff.c:189 [inline]
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
sp : ffff800096f97000
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
Call trace:
skb_panic net/core/skbuff.c:189 [inline]
skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
skb_push+0xf0/0x108 net/core/skbuff.c:2451
eth_header+0x44/0x1f8 net/ethernet/eth.c:83
dev_hard_header include/linux/netdevice.h:3188 [inline]
llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
llc_sap_next_state net/llc/llc_sap.c:182 [inline]
llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
sock_sendmsg+0x194/0x274 net/socket.c:767
splice_to_socket+0x7cc/0xd58 fs/splice.c:881
do_splice_from fs/splice.c:933 [inline]
direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
do_splice_direct+0x20c/0x348 fs/splice.c:1194
do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
__arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
CVE-2024-26636
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
Call pskb_inet_may_pull() to fix this, and initialize ipv6h
variable after this call as it can change skb->head.
[1]
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
__INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
__ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
gre_rcv+0x143f/0x1870
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
dst_input include/net/dst.h:461 [inline]
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
NF_HOOK include/linux/netfilter.h:314 [inline]
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
__netif_receive_skb_one_core net/core/dev.c:5532 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
netif_receive_skb_internal net/core/dev.c:5732 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5791
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2084 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0x786/0x1200 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
alloc_skb include/linux/skbuff.h:1286 [inline]
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
tun_alloc_skb drivers/net/tun.c:1531 [inline]
tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
call_write_iter include/linux/fs.h:2084 [inline]
new_sync_write fs/read_write.c:497 [inline]
vfs_write+0x786/0x1200 fs/read_write.c:590
ksys_write+0x20f/0x4c0 fs/read_write.c:643
__do_sys_write fs/read_write.c:655 [inline]
__se_sys_write fs/read_write.c:652 [inline]
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
CVE-2024-26641
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow anonymous set with timeout flag
Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
CVE-2024-26642
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sr9800: Add check for usbnet_get_endpoints
Add check for usbnet_get_endpoints() and return the error if it fails
in order to transfer the error.
CVE-2024-26651
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xhci: handle isoc Babble and Buffer Overrun events properly
xHCI 4.9 explicitly forbids assuming that the xHC has released its
ownership of a multi-TRB TD when it reports an error on one of the
early TRBs. Yet the driver makes such assumption and releases the TD,
allowing the remaining TRBs to be freed or overwritten by new TDs.
The xHC should also report completion of the final TRB due to its IOC
flag being set by us, regardless of prior errors. This event cannot
be recognized if the TD has already been freed earlier, resulting in
"Transfer event TRB DMA ptr not part of current TD" error message.
Fix this by reusing the logic for processing isoc Transaction Errors.
This also handles hosts which fail to report the final completion.
Fix transfer length reporting on Babble errors. They may be caused by
device malfunction, no guarantee that the buffer has been filled.
CVE-2024-26659
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
syzbot reported the following general protection fault [1]:
general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
<TASK>
tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
__sys_sendmsg+0x117/0x1e0 net/socket.c:2667
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The cause of this issue is that when tipc_nl_bearer_add() is called with
the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
even if the bearer is not UDP.
tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
the media_ptr field of the tipc_bearer has an udp_bearer type object, so
the function goes crazy for non-UDP bearers.
This patch fixes the issue by checking the bearer type before calling
tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
CVE-2024-26663
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_limit: reject configurations that cause integer overflow
Reject bogus configs where internal token counter wraps around.
This only occurs with very very large requests, such as 17gbyte/s.
Its better to reject this rather than having incorrect ratelimit.
CVE-2024-26668
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix IO hang from sbitmap wakeup race
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
with the following blk_mq_get_driver_tag() in case of getting driver
tag failure.
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
blk_mq_mark_tag_wait() can't get driver tag successfully.
This issue can be reproduced by running the following test in loop, and
fio hang can be observed in < 30min when running it on my test VM
in laptop.
modprobe -r scsi_debug
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
--runtime=100 --numjobs=40 --time_based --name=test \
--ioengine=libaio
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
is just fine in case of running out of tag.
CVE-2024-26671
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ppp_async: limit MRU to 64K
syzbot triggered a warning [1] in __alloc_pages():
WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")
Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)
[1]:
WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Workqueue: events_unbound flush_to_ldisc
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
sp : ffff800093967580
x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
Call trace:
__alloc_pages+0x308/0x698 mm/page_alloc.c:4543
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
__kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
__do_kmalloc_node mm/slub.c:3969 [inline]
__kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
__alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
__netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
dev_alloc_skb include/linux/skbuff.h:3248 [inline]
ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
receive_buf drivers/tty/tty_buffer.c:444 [inline]
flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
process_scheduled_works kernel/workqueue.c:2706 [inline]
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
kthread+0x288/0x310 kernel/kthread.c:388
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
CVE-2024-26675
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
inet: read sk->sk_family once in inet_recv_error()
inet_recv_error() is called without holding the socket lock.
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
socket option and trigger a KCSAN warning.
CVE-2024-26679
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xen/events: close evtchn after mapping cleanup
shutdown_pirq and startup_pirq are not taking the
irq_mapping_update_lock because they can't due to lock inversion. Both
are called with the irq_desc->lock being taking. The lock order,
however, is first irq_mapping_update_lock and then irq_desc->lock.
This opens multiple races:
- shutdown_pirq can be interrupted by a function that allocates an event
channel:
CPU0 CPU1
shutdown_pirq {
xen_evtchn_close(e)
__startup_pirq {
EVTCHNOP_bind_pirq
-> returns just freed evtchn e
set_evtchn_to_irq(e, irq)
}
xen_irq_info_cleanup() {
set_evtchn_to_irq(e, -1)
}
}
Assume here event channel e refers here to the same event channel
number.
After this race the evtchn_to_irq mapping for e is invalid (-1).
- __startup_pirq races with __unbind_from_irq in a similar way. Because
__startup_pirq doesn't take irq_mapping_update_lock it can grab the
evtchn that __unbind_from_irq is currently freeing and cleaning up. In
this case even though the event channel is allocated, its mapping can
be unset in evtchn_to_irq.
The fix is to first cleanup the mappings and then close the event
channel. In this way, when an event channel gets allocated it's
potential previous evtchn_to_irq mappings are guaranteed to be unset already.
This is also the reverse order of the allocation where first the event
channel is allocated and then the mappings are setup.
On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal
[un]bind interfaces"), we hit a BUG like the following during probing of NVMe
devices. The issue is that during nvme_setup_io_queues, pci_free_irq
is called for every device which results in a call to shutdown_pirq.
With many nvme devices it's therefore likely to hit this race during
boot because there will be multiple calls to shutdown_pirq and
startup_pirq are running potentially in parallel.
------------[ cut here ]------------
blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled
kernel BUG at drivers/xen/events/events_base.c:499!
invalid opcode: 0000 [#1] SMP PTI
CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1
Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
Workqueue: nvme-reset-wq nvme_reset_work
RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0
Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00
RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff
RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed
R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002
FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? show_trace_log_lvl+0x1c1/0x2d9
? show_trace_log_lvl+0x1c1/0x2d9
? set_affinity_irq+0xdc/0x1c0
? __die_body.cold+0x8/0xd
? die+0x2b/0x50
? do_trap+0x90/0x110
? bind_evtchn_to_cpu+0xdf/0xf0
? do_error_trap+0x65/0x80
? bind_evtchn_to_cpu+0xdf/0xf0
? exc_invalid_op+0x4e/0x70
? bind_evtchn_to_cpu+0xdf/0xf0
? asm_exc_invalid_op+0x12/0x20
? bind_evtchn_to_cpu+0xdf/0x
---truncated---
CVE-2024-26687
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ceph: prevent use-after-free in encode_cap_msg()
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
implies before the refcount could be increment here, it was freed.
In same file, in "handle_cap_grant()" refcount is decremented by this
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
occurred and resource was freed by the latter line before the former
line could increment it.
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
the refcount must be increased to prevent "use after free" error.
CVE-2024-26689
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double-free of blocks due to wrong extents moved_len
In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.
If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.
Therefore, update move_len after each extent move to avoid the issue.
CVE-2024-26704
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-26720
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arp: Prevent overflow in arp_req_get().
syzkaller reported an overflown write in arp_req_get(). [0]
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
the sa_data buffer is just 14 bytes.
In the splat below, 2 bytes are overflown to the next int field,
arp_flags. We initialise the field just after the memcpy(), so it's
not a problem.
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
in arp_ioctl() before calling arp_req_get().
To avoid the overflow, let's limit the max length of memcpy().
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
array in struct sockaddr") just silenced syzkaller.
[0]:
memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Modules linked in:
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
sock_do_ioctl+0xdf/0x260 net/socket.c:1204
sock_ioctl+0x3ef/0x650 net/socket.c:1321
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x64/0xce
RIP: 0033:0x7f172b262b8d
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 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:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
</TASK>
CVE-2024-26733
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix possible use-after-free and null-ptr-deref
The pernet operations structure for the subsystem must be registered
before registering the generic netlink family.
CVE-2024-26735
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: don't override retval if we already lost the skb
If we're redirecting the skb, and haven't called tcf_mirred_forward(),
yet, we need to tell the core to drop the skb by setting the retcode
to SHOT. If we have called tcf_mirred_forward(), however, the skb
is out of our hands and returning SHOT will lead to UaF.
Move the retval override to the error path which actually need it.
CVE-2024-26739
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: use the backlog for mirred ingress
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
for nested calls to mirred ingress") hangs our testing VMs every 10 or so
runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
lockdep.
The problem as previously described by Davide (see Link) is that
if we reverse flow of traffic with the redirect (egress -> ingress)
we may reach the same socket which generated the packet. And we may
still be holding its socket lock. The common solution to such deadlocks
is to put the packet in the Rx backlog, rather than run the Rx path
inline. Do that for all egress -> ingress reversals, not just once
we started to nest mirred calls.
In the past there was a concern that the backlog indirection will
lead to loss of error reporting / less accurate stats. But the current
workaround does not seem to address the issue.
CVE-2024-26740
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix qedr_create_user_qp error flow
Avoid the following warning by making sure to free the allocated
resources in case that qedr_init_user_queue() fail.
-----------[ cut here ]-----------
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
Call Trace:
<TASK>
? show_trace_log_lvl+0x1c4/0x2df
? show_trace_log_lvl+0x1c4/0x2df
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? __warn+0x81/0x110
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? report_bug+0x10a/0x140
? handle_bug+0x3c/0x70
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
__fput+0x94/0x250
task_work_run+0x5c/0x90
do_exit+0x270/0x4a0
do_group_exit+0x2d/0x90
get_signal+0x87c/0x8c0
arch_do_signal_or_restart+0x25/0x100
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
exit_to_user_mode_loop+0x9c/0x130
exit_to_user_mode_prepare+0xb6/0x100
syscall_exit_to_user_mode+0x12/0x40
do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
? common_interrupt+0x43/0xa0
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x1470abe3ec6b
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
</TASK>
--[ end trace 888a9b92e04c5c97 ]--
CVE-2024-26743
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Support specifying the srpt_service_guid parameter
Make loading ib_srpt with this parameter set work. The current behavior is
that setting that parameter while loading the ib_srpt kernel module
triggers the following kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
<TASK>
parse_one+0x18c/0x1d0
parse_args+0xe1/0x230
load_module+0x8de/0xa60
init_module_from_file+0x8b/0xd0
idempotent_init_module+0x181/0x240
__x64_sys_finit_module+0x5a/0xb0
do_syscall_64+0x5f/0xe0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
CVE-2024-26744
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: roles: fix NULL pointer issue when put module's reference
In current design, usb role class driver will get usb_role_switch parent's
module reference after the user get usb_role_switch device and put the
reference after the user put the usb_role_switch device. However, the
parent device of usb_role_switch may be removed before the user put the
usb_role_switch. If so, then, NULL pointer issue will be met when the user
put the parent module's reference.
This will save the module pointer in structure of usb_role_switch. Then,
we don't need to find module by iterating long relations.
CVE-2024-26747
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6_append_data
l2tp_ip6_sendmsg needs to avoid accounting for the transport header
twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using
skb_queue_empty when deciding how much data to append using
ip6_append_data.
However, the code which performed the calculation was incorrect:
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to
transhdrlen for messages with a non-zero length, which results in
corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original
intent.
CVE-2024-26752
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm-crypt: don't modify the data when using authenticated encryption
It was said that authenticated encryption could produce invalid tag when
the data that is being encrypted is modified [1]. So, fix this problem by
copying the data into the clone bio first and then encrypt them inside the
clone bio.
This may reduce performance, but it is needed to prevent the user from
corrupting the device by writing data with O_DIRECT and modifying them at
the same time.
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/
CVE-2024-26763
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: edma: Add some null pointer checks to the edma_probe
devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
CVE-2024-26771
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
Places the logic for checking if the group's block bitmap is corrupt under
the protection of the group lock to avoid allocating blocks from the group
with a corrupted block bitmap.
CVE-2024-26772
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
Determine if the group block bitmap is corrupted before using ac_b_ex in
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
corrupted block bitmap in the following concurrency and making the
situation worse.
ext4_mb_regular_allocator
ext4_lock_group(sb, group)
ext4_mb_good_group
// check if the group bbitmap is corrupted
ext4_mb_complex_scan_group
// Scan group gets ac_b_ex but doesn't use it
ext4_unlock_group(sb, group)
ext4_mark_group_bitmap_corrupted(group)
// The block bitmap was corrupted during
// the group unlock gap.
ext4_mb_try_best_found
ext4_lock_group(ac->ac_sb, group)
ext4_mb_use_best_found
mb_mark_used
// Allocating blocks in block bitmap corrupted group
CVE-2024-26773
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
aoe: avoid potential deadlock at set_capacity
Move set_capacity() outside of the section procected by (&d->lock).
To avoid possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
[1] lock(&bdev->bd_size_lock);
local_irq_disable();
[2] lock(&d->lock);
[3] lock(&bdev->bd_size_lock);
<Interrupt>
[4] lock(&d->lock);
*** DEADLOCK ***
Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().
[2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()
is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.
In this situation an attempt to acquire [4]lock(&d->lock) from
aoecmd_cfg_rsp() will lead to deadlock.
So the simplest solution is breaking lock dependency
[2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()
outside.
CVE-2024-26775
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sis: Error out if pixclock equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
In sisfb_check_var(), var->pixclock is used as a divisor to caculate
drate before it is checked against zero. Fix this by checking it
at the beginning.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.
CVE-2024-26777
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: Error out if pixclock equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
Although pixclock is checked in savagefb_decode_var(), but it is not
checked properly in savagefb_probe(). Fix this by checking whether
pixclock is zero in the function savagefb_check_var() before
info->var.pixclock is used as the divisor.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.
CVE-2024-26778
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix race condition on enabling fast-xmit
fast-xmit must only be enabled after the sta has been uploaded to the driver,
otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls
to the driver, leading to potential crashes because of uninitialized drv_priv
data.
Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.
CVE-2024-26779
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: dev-replace: properly validate device names
There's a syzbot report that device name buffers passed to device
replace are not properly checked for string termination which could lead
to a read out of bounds in getname_kernel().
Add a helper that validates both source and target device name buffers.
For devid as the source initialize the buffer to empty string in case
something tries to read it later.
This was originally analyzed and fixed in a different way by Edward Adam
Davis (see links).
CVE-2024-26791
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
The gtp_link_ops operations structure for the subsystem must be
registered after registering the gtp_net_ops pernet operations structure.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
[ 1010.702740] gtp: GTP module unloaded
[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1
[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]
[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00
[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203
[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000
[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282
[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000
[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80
[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400
[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000
[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0
[ 1010.715968] PKRU: 55555554
[ 1010.715972] Call Trace:
[ 1010.715985] ? __die_body.cold+0x1a/0x1f
[ 1010.715995] ? die_addr+0x43/0x70
[ 1010.716002] ? exc_general_protection+0x199/0x2f0
[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30
[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]
[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]
[ 1010.716042] __rtnl_newlink+0x1063/0x1700
[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0
[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0
[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0
[ 1010.716076] ? __kernel_text_address+0x56/0xa0
[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0
[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30
[ 1010.716098] ? arch_stack_walk+0x9e/0xf0
[ 1010.716106] ? stack_trace_save+0x91/0xd0
[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170
[ 1010.716121] ? __lock_acquire+0x15c5/0x5380
[ 1010.716139] ? mark_held_locks+0x9e/0xe0
[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0
[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700
[ 1010.716160] rtnl_newlink+0x69/0xa0
[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50
[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0
[ 1010.716179] ? lock_acquire+0x1fe/0x560
[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50
[ 1010.716196] netlink_rcv_skb+0x14d/0x440
[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0
[ 1010.716208] ? netlink_ack+0xab0/0xab0
[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50
[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50
[ 1010.716226] ? __virt_addr_valid+0x30b/0x590
[ 1010.716233] netlink_unicast+0x54b/0x800
[ 1010.716240] ? netlink_attachskb+0x870/0x870
[ 1010.716248] ? __check_object_size+0x2de/0x3b0
[ 1010.716254] netlink_sendmsg+0x938/0xe40
[ 1010.716261] ? netlink_unicast+0x800/0x800
[ 1010.716269] ? __import_iovec+0x292/0x510
[ 1010.716276] ? netlink_unicast+0x800/0x800
[ 1010.716284] __sock_sendmsg+0x159/0x190
[ 1010.716290] ____sys_sendmsg+0x712/0x880
[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0
[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270
[ 1010.716309] ? lock_acquire+0x1fe/0x560
[ 1010.716315] ? drain_array_locked+0x90/0x90
[ 1010.716324] ___sys_sendmsg+0xf8/0x170
[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170
[ 1010.716337] ? lockdep_init_map
---truncated---
CVE-2024-26793
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>]
? init_wait_entry+0x31/0x31
__hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>]
hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>]
process_one_work+0x1d8/0x33f
worker_thread+0x21b/0x373
kthread+0x13a/0x152
? pr_cont_work+0x54/0x54
? kthread_blkcg+0x31/0x31
ret_from_fork+0x1f/0x30
This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.
CVE-2024-26801
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ip_tunnel: prevent perpetual headroom growth
syzkaller triggered following kasan splat:
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
[..]
kasan_report+0xda/0x110 mm/kasan/report.c:588
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
skb_get_hash include/linux/skbuff.h:1556 [inline]
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
...
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
..
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
...
The splat occurs because skb->data points past skb->head allocated area.
This is because neigh layer does:
__skb_pull(skb, skb_network_offset(skb));
... but skb_network_offset() returns a negative offset and __skb_pull()
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
The negative value is returned because skb->head and skb->data distance is
more than 64k and skb->network_header (u16) has wrapped around.
The bug is in the ip_tunnel infrastructure, which can cause
dev->needed_headroom to increment ad infinitum.
The syzkaller reproducer consists of packets getting routed via a gre
tunnel, and route of gre encapsulated packets pointing at another (ipip)
tunnel. The ipip encapsulation finds gre0 as next output device.
This results in the following pattern:
1). First packet is to be sent out via gre0.
Route lookup found an output device, ipip0.
2).
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
output device, rt.dev->needed_headroom (ipip0).
3).
ip output / start_xmit moves skb on to ipip0. which runs the same
code path again (xmit recursion).
4).
Routing step for the post-gre0-encap packet finds gre0 as output device
to use for ipip0 encapsulated packet.
tunl0->needed_headroom is then incremented based on the (already bumped)
gre0 device headroom.
This repeats for every future packet:
gre0->needed_headroom gets inflated because previous packets' ipip0 step
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
needed_headroom was increased.
For each subsequent packet, gre/ipip0->needed_headroom grows until
post-expand-head reallocations result in a skb->head/data distance of
more than 64k.
Once that happens, skb->network_header (u16) wraps around when
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
after the headroom expansion/reallocation.
After this skb_network_offset(skb) returns a different (and negative)
result post headroom expansion.
The next trip to neigh layer (or anything else that would __skb_pull the
network header) makes skb->data point to a memory location outside
skb->head area.
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
prevent perpetual increase instead of dropping the headroom increment
completely.
CVE-2024-26804
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
syzbot reported the following uninit-value access issue [1]:
netlink_to_full_skb() creates a new `skb` and puts the `skb->data`
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
size is specified as `len` and passed to skb_put_data(). This `len`
is based on `skb->end` that is not data offset but buffer offset. The
`skb->end` contains data and tailroom. Since the tailroom is not
initialized when the new `skb` created, KMSAN detects uninitialized
memory area when copying the data.
This patch resolved this issue by correct the len from `skb->end` to
`skb->len`, which is the actual data offset.
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
copy_to_user_iter lib/iov_iter.c:24 [inline]
iterate_ubuf include/linux/iov_iter.h:29 [inline]
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
iterate_and_advance include/linux/iov_iter.h:271 [inline]
_copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
copy_to_iter include/linux/uio.h:197 [inline]
simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
sock_recvmsg_nosec net/socket.c:1044 [inline]
sock_recvmsg net/socket.c:1066 [inline]
sock_read_iter+0x467/0x580 net/socket.c:1136
call_read_iter include/linux/fs.h:2014 [inline]
new_sync_read fs/read_write.c:389 [inline]
vfs_read+0x8f6/0xe00 fs/read_write.c:470
ksys_read+0x20f/0x4c0 fs/read_write.c:613
__do_sys_read fs/read_write.c:623 [inline]
__se_sys_read fs/read_write.c:621 [inline]
__x64_sys_read+0x93/0xd0 fs/read_write.c:621
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was stored to memory at:
skb_put_data include/linux/skbuff.h:2622 [inline]
netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
__netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
__netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
free_pages_prepare mm/page_alloc.c:1087 [inline]
free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
release_pages+0x23d3/0x2410 mm/swap.c:1042
free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
tlb_batch_pages
---truncated---
CVE-2024-26805
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Create persistent INTx handler
A vulnerability exists where the eventfd for INTx signaling can be
deconfigured, which unregisters the IRQ handler but still allows
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
or through unmask irqfd if the device interrupt is pending.
Ideally this could be solved with some additional locking; the igate
mutex serializes the ioctl and config space accesses, and the interrupt
handler is unregistered relative to the trigger, but the irqfd path
runs asynchronous to those. The igate mutex cannot be acquired from the
atomic context of the eventfd wake function. Disabling the irqfd
relative to the eventfd registration is potentially incompatible with
existing userspace.
As a result, the solution implemented here moves configuration of the
INTx interrupt handler to track the lifetime of the INTx context object
and irq_type configuration, rather than registration of a particular
trigger eventfd. Synchronization is added between the ioctl path and
eventfd_signal() wrapper such that the eventfd trigger can be
dynamically updated relative to in-flight interrupts or irqfd callbacks.
CVE-2024-26812
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: Create persistent IRQ handlers
The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.
Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path. This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal. This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.
In doing so, it's guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.
For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index.
CVE-2024-26813
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86, relocs: Ignore relocations in .notes section
When building with CONFIG_XEN_PV=y, .text symbols are emitted into
the .notes section so that Xen can find the "startup_xen" entry point.
This information is used prior to booting the kernel, so relocations
are not useful. In fact, performing relocations against the .notes
section means that the KASLR base is exposed since /sys/kernel/notes
is world-readable.
To avoid leaking the KASLR base without breaking unprivileged tools that
are expecting to read /sys/kernel/notes, skip performing relocations in
the .notes section. The values readable in .notes are then identical to
those found in System.map.
CVE-2024-26816
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
amdkfd: use calloc instead of kzalloc to avoid integer overflow
This uses calloc instead of doing the multiplication which might
overflow.
CVE-2024-26817
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: free rx_data_reassembly skb on NCI device cleanup
rx_data_reassembly skb is stored during NCI data exchange for processing
fragmented packets. It is dropped only when the last fragment is processed
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
However, the NCI device may be deallocated before that which leads to skb
leak.
As by design the rx_data_reassembly skb is bound to the NCI device and
nothing prevents the device to be freed before the skb is processed in
some way and cleaned, free it on the NCI device cleanup.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2024-26825
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix underflow in parse_server_interfaces()
In this loop, we step through the buffer and after each item we check
if the size_left is greater than the minimum size we need. However,
the problem is that "bytes_left" is type ssize_t while sizeof() is type
size_t. That means that because of type promotion, the comparison is
done as an unsigned and if we have negative bytes left the loop
continues instead of ending.
CVE-2024-26828
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
CVE-2024-26830
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix a memleak in init_credit_return
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
init_credit_return should deallocate dd->cr_base and
dd->cr_base[i] that allocated before. Or those resources
would be never freed and a memleak is triggered.
CVE-2024-26839
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix memory leak in cachefiles_add_cache()
The following memory leak was reported after unbinding /dev/cachefiles:
==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
comm "cachefilesd2", pid 680, jiffies 4294881224
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc ea38a44b):
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
fix the problem. And also put cache_cred in cachefiles_add_cache() error
branch to avoid memory leaks.
CVE-2024-26840
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: core: Add TMF to tmr_list handling
An abort that is responded to by iSCSI itself is added to tmr_list but does
not go to target core. A LUN_RESET that goes through tmr_list takes a
refcounter on the abort and waits for completion. However, the abort will
be never complete because it was not started in target core.
Unable to locate ITT: 0x05000000 on CID: 0
Unable to locate RefTaskTag: 0x05000000 on CID: 0.
wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
...
INFO: task kworker/0:2:49 blocked for more than 491 seconds.
task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800
Workqueue: events target_tmr_work [target_core_mod]
Call Trace:
__switch_to+0x2c4/0x470
_schedule+0x314/0x1730
schedule+0x64/0x130
schedule_timeout+0x168/0x430
wait_for_completion+0x140/0x270
target_put_cmd_and_wait+0x64/0xb0 [target_core_mod]
core_tmr_lun_reset+0x30/0xa0 [target_core_mod]
target_tmr_work+0xc8/0x1b0 [target_core_mod]
process_one_work+0x2d4/0x5d0
worker_thread+0x78/0x6c0
To fix this, only add abort to tmr_list if it will be handled by target
core.
CVE-2024-26845
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: do not wait in vain when unloading module
The module exit path has race between deleting all controllers and
freeing 'left over IDs'. To prevent double free a synchronization
between nvme_delete_ctrl and ida_destroy has been added by the initial
commit.
There is some logic around trying to prevent from hanging forever in
wait_for_completion, though it does not handling all cases. E.g.
blktests is able to reproduce the situation where the module unload
hangs forever.
If we completely rely on the cleanup code executed from the
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
calling ida_destroy unnecessary. We only have to ensure that all
nvme_delete_ctrl code has been executed before we leave
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
workqueue.
While at it, remove the unused nvme_fc_wq workqueue too.
CVE-2024-26846
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
that are out of bounds for their data type.
vmlinux get_bitmap(b=75) + 712
<net/netfilter/nf_conntrack_h323_asn1.c:0>
vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
<net/netfilter/nf_conntrack_h323_asn1.c:592>
vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
<net/netfilter/nf_conntrack_h323_asn1.c:814>
vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
<net/netfilter/nf_conntrack_h323_asn1.c:576>
vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
<net/netfilter/nf_conntrack_h323_asn1.c:814>
vmlinux DecodeRasMessage() + 304
<net/netfilter/nf_conntrack_h323_asn1.c:833>
vmlinux ras_help() + 684
<net/netfilter/nf_conntrack_h323_main.c:1728>
vmlinux nf_confirm() + 188
<net/netfilter/nf_conntrack_proto.c:137>
Due to abnormal data in skb->data, the extension bitmap length
exceeds 32 when decoding ras message then uses the length to make
a shift operation. It will change into negative after several loop.
UBSAN load could detect a negative shift as an undefined behaviour
and reports exception.
So we add the protection to avoid the length exceeding 32. Or else
it will return out of range error and stop decoding.
CVE-2024-26851
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
Commit f7225172f25a ("net/ipv6: prevent use after free in
ip6_route_mpath_notify") was not able to fix the root cause.
We need to defer the fib6_info_release() calls after
ip6_route_mpath_notify(), in the cleanup phase.
[1]
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x167/0x540 mm/kasan/report.c:488
kasan_report+0x142/0x180 mm/kasan/report.c:601
rt6_fill_node+0x1460/0x1ac0
inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
do_syscall_64+0xf9/0x240
entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f73dd87dda9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
</TASK>
Allocated by task 23037:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
kasan_kmalloc include/linux/kasan.h:211 [inline]
__do_kmalloc_node mm/slub.c:3981 [inline]
__kmalloc+0x22e/0x490 mm/slub.c:3994
kmalloc include/linux/slab.h:594 [inline]
kzalloc include/linux/slab.h:711 [inline]
fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
do_syscall_64+0xf9/0x240
entry_SYSCALL_64_after_hwframe+0x6f/0x77
Freed by task 16:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
poison_slab_object+0xa6/0xe0 m
---truncated---
CVE-2024-26852
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
The function ice_bridge_setlink() may encounter a NULL pointer dereference
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
in nla_for_each_nested(). To address this issue, add a check to ensure that
br_spec is not NULL before proceeding with the nested attribute iteration.
CVE-2024-26855
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
geneve: make sure to pull inner header in geneve_rx()
syzbot triggered a bug in geneve_rx() [1]
Issue is similar to the one I fixed in commit 8d975c15c0cd
("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
We have to save skb->network_header in a temporary variable
in order to be able to recompute the network_header pointer
after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
[1]
BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]
BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
geneve_rx drivers/net/geneve.c:279 [inline]
geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108
udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186
udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346
__udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422
udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604
ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:461 [inline]
ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
__netif_receive_skb_one_core net/core/dev.c:5534 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
process_backlog+0x480/0x8b0 net/core/dev.c:5976
__napi_poll+0xe3/0x980 net/core/dev.c:6576
napi_poll net/core/dev.c:6645 [inline]
net_rx_action+0x8b8/0x1870 net/core/dev.c:6778
__do_softirq+0x1b7/0x7c5 kernel/softirq.c:553
do_softirq+0x9a/0xf0 kernel/softirq.c:454
__local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]
__dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378
dev_queue_xmit include/linux/netdevice.h:3171 [inline]
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3081 [inline]
packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3819 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x352/0x790 net/core/skbuff.c:651
alloc_skb include/linux/skbuff.h:1296 [inline]
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783
packet_alloc_skb net/packet/af_packet.c:2930 [inline]
packet_snd net/packet/af_packet.c:3024 [inline]
packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVE-2024-26857
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/bnx2x: Prevent access to a freed page in page_pool
Fix race condition leading to system crash during EEH error handling
During EEH error recovery, the bnx2x driver's transmit timeout logic
could cause a race condition when handling reset tasks. The
bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
overlap with the EEH driver's attempt to reset the device using
bnx2x_io_slot_reset(), which also tries to free SGEs. This race
condition can result in system crashes due to accessing freed memory
locations in bnx2x_free_rx_sge()
799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
800 struct bnx2x_fastpath *fp, u16 index)
801 {
802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];
803 struct page *page = sw_buf->page;
....
where sw_buf was set to NULL after the call to dma_unmap_page()
by the preceding thread.
EEH: Beginning: 'slot_reset'
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000025065fc
Oops: Kernel access of bad area, sig: 11 [#1]
.....
Call Trace:
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
To solve this issue, we need to verify page pool allocations before
freeing.
CVE-2024-26859
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hsr: Fix uninit-value access in hsr_get_node()
KMSAN reported the following uninit-value access issue [1]:
=====================================================
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
fill_frame_info net/hsr/hsr_forward.c:577 [inline]
hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
alloc_skb include/linux/skbuff.h:1286 [inline]
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
packet_alloc_skb net/packet/af_packet.c:2936 [inline]
packet_snd net/packet/af_packet.c:3030 [inline]
packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x735/0xa10 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
=====================================================
If the packet type ID field in the Ethernet header is either ETH_P_PRP or
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
reads an invalid value as a sequence number. This causes the above issue.
This patch fixes the issue by returning NULL if the Ethernet header is not
followed by an HSR tag.
CVE-2024-26863
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Do not register event handler until srpt device is fully setup
Upon rare occasions, KASAN reports a use-after-free Write
in srpt_refresh_port().
This seems to be because an event handler is registered before the
srpt device is fully setup and a race condition upon error may leave a
partially setup event handler in place.
Instead, only register the event handler after srpt device initialization
is complete.
CVE-2024-26872
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip
It's possible that mtk_crtc->event is NULL in
mtk_drm_crtc_finish_page_flip().
pending_needs_vblank value is set by mtk_crtc->event, but in
mtk_drm_crtc_atomic_flush(), it's is not guarded by the same
lock in mtk_drm_finish_page_flip(), thus a race condition happens.
Consider the following case:
CPU1 CPU2
step 1:
mtk_drm_crtc_atomic_begin()
mtk_crtc->event is not null,
step 1:
mtk_drm_crtc_atomic_flush:
mtk_drm_crtc_update_config(
!!mtk_crtc->event)
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip:
lock
mtk_crtc->event set to null,
pending_needs_vblank set to false
unlock
pending_needs_vblank set to true,
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip called again,
pending_needs_vblank is still true
//null pointer
Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more
efficient to just check if mtk_crtc->event is null before use.
CVE-2024-26874
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix uaf in pvr2_context_set_notify
[Syzbot reported]
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:488
kasan_report+0xda/0x110 mm/kasan/report.c:601
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
Freed by task 906:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inline]
slab_free mm/slub.c:4299 [inline]
kfree+0x105/0x340 mm/slub.c:4409
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
[Analyze]
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
and releasing mp, leading to this issue.
[Fix]
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
to avoid this issue.
CVE-2024-26875
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: adv7511: fix crash on irq during probe
Moved IRQ registration down to end of adv7511_probe().
If an IRQ already is pending during adv7511_probe
(before adv7511_cec_init) then cec_received_msg_ts
could crash using uninitialized data:
Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5
Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
Call trace:
cec_received_msg_ts+0x48/0x990 [cec]
adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
adv7511_irq_process+0xd8/0x120 [adv7511]
adv7511_irq_handler+0x1c/0x30 [adv7511]
irq_thread_fn+0x30/0xa0
irq_thread+0x14c/0x238
kthread+0x190/0x1a8
CVE-2024-26876
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
quota: Fix potential NULL pointer dereference
Below race may cause NULL pointer dereference
P1 P2
dquot_free_inode quota_off
drop_dquot_ref
remove_dquot_ref
dquots = i_dquot(inode)
dquots = i_dquot(inode)
srcu_read_lock
dquots[cnt]) != NULL (1)
dquots[type] = NULL (2)
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
....
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
dereference will be triggered.
So let's fix it by using a temporary pointer to avoid this issue.
CVE-2024-26878
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm: call the resume method on internal suspend
There is this reported crash when experimenting with the lvm2 testsuite.
The list corruption is caused by the fact that the postsuspend and resume
methods were not paired correctly; there were two consecutive calls to the
origin_postsuspend function. The second call attempts to remove the
"hash_list" entry from a list, while it was already removed by the first
call.
Fix __dm_internal_resume so that it calls the preresume and resume
methods of the table's targets.
If a preresume method of some target fails, we are in a tricky situation.
We can't return an error because dm_internal_resume isn't supposed to
return errors. We can't return success, because then the "resume" and
"postsuspend" methods would not be paired correctly. So, we set the
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
tools, but it won't cause a kernel crash.
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:56!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
<snip>
RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282
RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff
RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058
R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001
R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0
FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0
Call Trace:
<TASK>
? die+0x2d/0x80
? do_trap+0xeb/0xf0
? __list_del_entry_valid_or_report+0x77/0xc0
? do_error_trap+0x60/0x80
? __list_del_entry_valid_or_report+0x77/0xc0
? exc_invalid_op+0x49/0x60
? __list_del_entry_valid_or_report+0x77/0xc0
? asm_exc_invalid_op+0x16/0x20
? table_deps+0x1b0/0x1b0 [dm_mod]
? __list_del_entry_valid_or_report+0x77/0xc0
origin_postsuspend+0x1a/0x50 [dm_snapshot]
dm_table_postsuspend_targets+0x34/0x50 [dm_mod]
dm_suspend+0xd8/0xf0 [dm_mod]
dev_suspend+0x1f2/0x2f0 [dm_mod]
? table_deps+0x1b0/0x1b0 [dm_mod]
ctl_ioctl+0x300/0x5f0 [dm_mod]
dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]
__x64_compat_sys_ioctl+0x104/0x170
do_syscall_64+0x184/0x1b0
entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0xf7e6aead
<snip>
---[ end trace 0000000000000000 ]---
CVE-2024-26880
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stackmap overflow check on 32-bit arches
The stackmap code relies on roundup_pow_of_two() to compute the number
of hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code.
The commit in the fixes tag actually attempted to fix this, but the fix
did not account for the UB, so the fix only works on CPUs where an
overflow does result in a neat truncation to zero, which is not
guaranteed. Checking the value before rounding does not have this
problem.
CVE-2024-26883
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix hashtab overflow check on 32-bit arches
The hashtab code relies on roundup_pow_of_two() to compute the number of
hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code. So apply the same
fix to hashtab, by moving the overflow check to before the roundup.
CVE-2024-26884
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: af_bluetooth: Fix deadlock
Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
bellow, so instead of using sock_sock this uses sk_receive_queue.lock
on bt_sock_ioctl to avoid the UAF:
INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
Not tainted 6.7.6-lemon #183
Workqueue: hci0 hci_rx_work
Call Trace:
<TASK>
__schedule+0x37d/0xa00
schedule+0x32/0xe0
__lock_sock+0x68/0xa0
? __pfx_autoremove_wake_function+0x10/0x10
lock_sock_nested+0x43/0x50
l2cap_sock_recv_cb+0x21/0xa0
l2cap_recv_frame+0x55b/0x30a0
? psi_task_switch+0xeb/0x270
? finish_task_switch.isra.0+0x93/0x2a0
hci_rx_work+0x33a/0x3f0
process_one_work+0x13a/0x2f0
worker_thread+0x2f0/0x410
? __pfx_worker_thread+0x10/0x10
kthread+0xe0/0x110
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2c/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
CVE-2024-26886
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
[<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0
[<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0
[<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50
[<ffffffff99805872>] really_probe+0xe2/0x480
[<ffffffff99805c98>] __driver_probe_device+0x78/0x160
[<ffffffff99805daf>] driver_probe_device+0x1f/0x90
[<ffffffff9980601e>] __driver_attach+0xce/0x1c0
[<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
[<ffffffff99804822>] bus_add_driver+0x112/0x210
[<ffffffff99807245>] driver_register+0x55/0x100
[<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0
[<ffffffff990012d1>] do_one_initcall+0x41/0x300
[<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470
[<ffffffff99b231f6>] kernel_init+0x16/0x1b0
[<ffffffff99042e6d>] ret_from_fork+0x2d/0x50
Fix this by freeing the CPU idle device after unregistering it.
CVE-2024-26894
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev->serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
comm "mdadm", pid 789, jiffies 4294716910
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc f773277a):
[<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
[<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
[<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
[<00000000f206d60a>] kvmalloc_node+0x74/0x150
[<0000000034bf3363>] rdev_init_serial+0x67/0x170
[<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
[<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
[<0000000073c28560>] md_add_new_disk+0x400/0x9f0
[<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
[<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
[<0000000085086a11>] vfs_ioctl+0x22/0x60
[<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
[<00000000e54e675e>] do_syscall_64+0x71/0x150
[<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
CVE-2024-26900
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].
[1]
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
_copy_to_user+0xbc/0x100 lib/usercopy.c:40
copy_to_user include/linux/uaccess.h:191 [inline]
do_sys_name_to_handle fs/fhandle.c:73 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc+0x121/0x3c0 mm/slab_common.c:1020
kmalloc include/linux/slab.h:604 [inline]
do_sys_name_to_handle fs/fhandle.c:39 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240"
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem.
CVE-2024-26901
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
------------[ cut here ]------------
memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
[last unloaded: mlx_compat(OE)]
CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? show_regs+0x72/0x90
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
? __warn+0x8d/0x160
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
? report_bug+0x1bb/0x1d0
? handle_bug+0x46/0x90
? exc_invalid_op+0x19/0x80
? asm_exc_invalid_op+0x1b/0x20
? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
ipoib_send+0x2ec/0x770 [ib_ipoib]
ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
dev_hard_start_xmit+0x8e/0x1e0
? validate_xmit_skb_list+0x4d/0x80
sch_direct_xmit+0x116/0x3a0
__dev_xmit_skb+0x1fd/0x580
__dev_queue_xmit+0x284/0x6b0
? _raw_spin_unlock_irq+0xe/0x50
? __flush_work.isra.0+0x20d/0x370
? push_pseudo_header+0x17/0x40 [ib_ipoib]
neigh_connected_output+0xcd/0x110
ip_finish_output2+0x179/0x480
? __smp_call_single_queue+0x61/0xa0
__ip_finish_output+0xc3/0x190
ip_finish_output+0x2e/0xf0
ip_output+0x78/0x110
? __pfx_ip_finish_output+0x10/0x10
ip_local_out+0x64/0x70
__ip_queue_xmit+0x18a/0x460
ip_queue_xmit+0x15/0x30
__tcp_transmit_skb+0x914/0x9c0
tcp_write_xmit+0x334/0x8d0
tcp_push_one+0x3c/0x60
tcp_sendmsg_locked+0x2e1/0xac0
tcp_sendmsg+0x2d/0x50
inet_sendmsg+0x43/0x90
sock_sendmsg+0x68/0x80
sock_write_iter+0x93/0x100
vfs_write+0x326/0x3c0
ksys_write+0xbd/0xf0
? do_syscall_64+0x69/0x90
__x64_sys_write+0x19/0x30
do_syscall_
---truncated---
CVE-2024-26907
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Reset IH OVERFLOW_CLEAR bit
Allows us to detect subsequent IH ring buffer overflows as well.
CVE-2024-26915
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing/trigger: Fix to return error if failed to alloc snapshot
Fix register_snapshot_trigger() to return error code if it failed to
allocate a snapshot instead of 0 (success). Unless that, it will register
snapshot trigger without an error.
CVE-2024-26920
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
inet: inet_defrag: prevent sk release while still in use
ip_local_out() and other functions can pass skb->sk as function argument.
If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released.
This affects skb fragments reassembled via netfilter or similar
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
Eric Dumazet made an initial analysis of this bug. Quoting Eric:
Calling ip_defrag() in output path is also implying skb_orphan(),
which is buggy because output path relies on sk not disappearing.
A relevant old patch about the issue was :
8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
[..]
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
inet socket, not an arbitrary one.
If we orphan the packet in ipvlan, then downstream things like FQ
packet scheduler will not work properly.
We need to change ip_defrag() to only use skb_orphan() when really
needed, ie whenever frag_list is going to be used.
Eric suggested to stash sk in fragment queue and made an initial patch.
However there is a problem with this:
If skb is refragmented again right after, ip_do_fragment() will copy
head->sk to the new fragments, and sets up destructor to sock_wfree.
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
fully reassembled skb, else wmem will underflow.
This change moves the orphan down into the core, to last possible moment.
As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
offset into the FRAG_CB, else skb->sk gets clobbered.
This allows to delay the orphaning long enough to learn if the skb has
to be queued or if the skb is completing the reasm queue.
In the former case, things work as before, skb is orphaned. This is
safe because skb gets queued/stolen and won't continue past reasm engine.
In the latter case, we will steal the skb->sk reference, reattach it to
the head skb, and fix up wmem accouting when inet_frag inflates truesize.
CVE-2024-26921
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate the parameters of bo mapping operations more clearly
Verify the parameters of
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
CVE-2024-26922
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix garbage collector racing against connect()
Garbage collector does not take into account the risk of embryo getting
enqueued during the garbage collection. If such embryo has a peer that
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
different set of children. Leading to an incorrectly elevated inflight
count, and then a dangling pointer within the gc_inflight_list.
sockets are AF_UNIX/SOCK_STREAM
S is an unconnected socket
L is a listening in-flight socket bound to addr, not in fdtable
V's fd will be passed via sendmsg(), gets inflight count bumped
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
---------------- ------------------------- -----------
NS = unix_create1()
skb1 = sock_wmalloc(NS)
L = unix_find_other(addr)
unix_state_lock(L)
unix_peer(S) = NS
// V count=1 inflight=0
NS = unix_peer(S)
skb2 = sock_alloc()
skb_queue_tail(NS, skb2[V])
// V became in-flight
// V count=2 inflight=1
close(V)
// V count=1 inflight=1
// GC candidate condition met
for u in gc_inflight_list:
if (total_refs == inflight_refs)
add u to gc_candidates
// gc_candidates={L, V}
for u in gc_candidates:
scan_children(u, dec_inflight)
// embryo (skb1) was not
// reachable from L yet, so V's
// inflight remains unchanged
__skb_queue_tail(L, skb1)
unix_state_unlock(L)
for u in gc_candidates:
if (u.inflight)
scan_children(u, inc_inflight_move_tail)
// V count=1 inflight=2 (!)
If there is a GC-candidate listening socket, lock/unlock its state. This
makes GC wait until the end of any ongoing connect() to that socket. After
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
this point, unix_inflight() can not happen because unix_gc_lock is already
taken. Inflight graph remains unaffected.
CVE-2024-26923
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: do not free live element
Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern. Quoting Pablo:
add_elem("00000000") timeout 100 ms
...
add_elem("0000000X") timeout 100 ms
del_elem("0000000X") <---------------- delete one that was just added
...
add_elem("00005000") timeout 100 ms
1) nft_pipapo_remove() removes element 0000000X
Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one
element that share the same key.
This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.
The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).
Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.
v2: avoid uneeded temporary variable (Stefano)
CVE-2024-26924
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_debug_files_proc_show()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
CVE-2024-26928
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-26929
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix double free of the ha->vp_map pointer
Coverity scan reported potential risk of double free of the pointer
ha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freed
in function qla2x00_mem_free(ha).
Assign NULL to vp_map and kfree take care of NULL.
CVE-2024-26930
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix command flush on cable pull
System crash due to command failed to flush back to SCSI layer.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1
Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
RIP: 0010:__wake_up_common+0x4c/0x190
Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75
RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
__wake_up_common_lock+0x7c/0xc0
qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0
? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.
? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1
? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]
qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0
? __switch_to+0x10c/0x450
? process_one_work+0x1a7/0x360
qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.
? worker_thread+0x1ce/0x390
? create_worker+0x1a0/0x1a0
qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70
? kthread+0x10a/0x120
qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8
? set_kthread_struct+0x40/0x40
qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.
? ret_from_fork+0x1f/0x40
qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout
The system was under memory stress where driver was not able to allocate an
SRB to carry out error recovery of cable pull. The failure to flush causes
upper layer to start modifying scsi_cmnd. When the system frees up some
memory, the subsequent cable pull trigger another command flush. At this
point the driver access a null pointer when attempting to DMA unmap the
SGL.
Add a check to make sure commands are flush back on session tear down to
prevent the null pointer access.
CVE-2024-26931
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface's parent
USB device.
The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected. As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete. But usb_deauthorize_interface() can't complete
until the device lock has been released, and the lock won't be
released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>
Reported by: xingwei lee <xrivendell7@gmail.com>
CVE-2024-26934
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add a dc_state NULL check in dc_state_release
[How]
Check wheather state is NULL before releasing it.
CVE-2024-26948
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: fix reference counting on zcrypt card objects
Tests with hot-plugging crytpo cards on KVM guests with debug
kernel build revealed an use after free for the load field of
the struct zcrypt_card. The reason was an incorrect reference
handling of the zcrypt card object which could lead to a free
of the zcrypt card object while it was still in use.
This is an example of the slab message:
kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
kernel: kmalloc_trace+0x3f2/0x470
kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]
kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
kernel: ap_device_probe+0x15c/0x290
kernel: really_probe+0xd2/0x468
kernel: driver_probe_device+0x40/0xf0
kernel: __device_attach_driver+0xc0/0x140
kernel: bus_for_each_drv+0x8c/0xd0
kernel: __device_attach+0x114/0x198
kernel: bus_probe_device+0xb4/0xc8
kernel: device_add+0x4d2/0x6e0
kernel: ap_scan_adapter+0x3d0/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
kernel: kfree+0x37e/0x418
kernel: zcrypt_card_put+0x54/0x80 [zcrypt]
kernel: ap_device_remove+0x4c/0xe0
kernel: device_release_driver_internal+0x1c4/0x270
kernel: bus_remove_device+0x100/0x188
kernel: device_del+0x164/0x3c0
kernel: device_unregister+0x30/0x90
kernel: ap_scan_adapter+0xc8/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: kthread+0x150/0x168
kernel: __ret_from_fork+0x3c/0x58
kernel: ret_from_fork+0xa/0x30
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........
kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.
kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........
kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
kernel: Call Trace:
kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8
kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590
kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
kernel:
---truncated---
CVE-2024-26957
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
PKRU: 55555554
Call Trace:
<TASK>
? __warn+0x9f/0x130
? refcount_warn_saturate+0x9c/0xe0
? report_bug+0xcc/0x150
? handle_bug+0x3d/0x70
? exc_invalid_op+0x16/0x40
? asm_exc_invalid_op+0x16/0x20
? refcount_warn_saturate+0x9c/0xe0
nfs_direct_write_schedule_work+0x237/0x250 [nfs]
process_one_work+0x12f/0x4a0
worker_thread+0x14e/0x3b0
? ZSTD_getCParams_internal+0x220/0x220
kthread+0xdc/0x120
? __btf_name_valid+0xa0/0xa0
ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we
process them and send them off, and then in the completion path for the
commit requests we have
if (nfs_commit_end(cinfo.mds))
nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have
one that completes before we submit the next one, so we end up calling
complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in
__nfs_commit_inode, which wraps this call in a
nfs_commit_begin();
nfs_commit_end();
Which is a common pattern for this style of completion handling, one
that is also repeated in the direct code with get_dreq()/put_dreq()
calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop
every 10ish minutes. With my patch the stress test has been running for
several hours without popping.
CVE-2024-26958
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fat: fix uninitialized field in nostale filehandles
When fat_encode_fh_nostale() encodes file handle without a parent it
stores only first 10 bytes of the file handle. However the length of the
file handle must be a multiple of 4 so the file handle is actually 12
bytes long and the last two bytes remain uninitialized. This is not
great at we potentially leak uninitialized information with the handle
to userspace. Properly initialize the full handle length.
CVE-2024-26973
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver
may encounter a race condition with freeing the reset_data structure's
memory. If the device restart will take more than 10 seconds the function
scheduling that restart will exit due to a timeout, and the reset_data
structure will be freed. However, this data structure is used for
completion notification after the restart is completed, which leads
to a UAF bug.
This results in a KFENCE bug notice.
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
adf_device_reset_worker+0x38/0xa0 [intel_qat]
process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container
of the work_struct is freed on the worker if the timeout expired,
otherwise on the function that schedules the worker.
The timeout detection can be done by checking if the caller is
still waiting for completion or not by using completion_done() function.
CVE-2024-26974
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check the inode number is not the invalid value of zero
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode
has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following
sequence of events:
1. Fill_meta_index() is called to allocate (via empty_meta_index())
and fill a metadata index. It however suffers a data read error
and aborts, invalidating the newly returned empty metadata index.
It does this by setting the inode number of the index to zero,
which means unused (zero is not a valid inode number).
2. When fill_meta_index() is subsequently called again on another
read operation, locate_meta_index() returns the previous index
because it matches the inode number of 0. Because this index
has been returned it is expected to have been filled, and because
it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number
is not zero when the inode is created and returns -EINVAL if it is.
[phillip@squashfs.org.uk: whitespace fix]
CVE-2024-26982
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nouveau: fix instmem race condition around ptr stores
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1
RSP: 0000:ffffac20c5857838 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001
RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180
RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10
R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c
R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c
FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
...
? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]
nvkm_vmm_iter+0x351/0xa20 [nouveau]
? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
? __lock_acquire+0x3ed/0x2170
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]
? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]
Adding any sort of useful debug usually makes it go away, so I hand
wrote the function in a line, and debugged the asm.
Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in
the nv50_instobj_acquire called from nvkm_kmap.
If Thread A and Thread B both get to nv50_instobj_acquire around
the same time, and Thread A hits the refcount_set line, and in
lockstep thread B succeeds at refcount_inc_not_zero, there is a
chance the ptrs value won't have been stored since refcount_set
is unordered. Force a memory barrier here, I picked smp_mb, since
we want it on all CPUs and it's write followed by a read.
v2: use paired smp_rmb/smp_wmb.
CVE-2024-26984
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
The sysfs_break_active_protection() routine has an obvious reference
leak in its error path. If the call to kernfs_find_and_get() fails then
kn will be NULL, so the companion sysfs_unbreak_active_protection()
routine won't get called (and would only cause an access violation by
trying to dereference kn->parent if it was called). As a result, the
reference to kobj acquired at the start of the function will never be
released.
Fix the leak by adding an explicit kobject_put() call when kn is NULL.
CVE-2024-26993
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down,
eth_stop() is called. At this piont, accidentally if usb transport error
should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
After that, ncm_disable() is called to disable for ncm unbind
but gether_disconnect() is never called since 'in_ep' is not enabled.
As the result, ncm object is released in ncm unbind
but 'dev->port_usb' associated to 'ncm->port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated
but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and eth_start_xmit() is called,
released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs]
usb0: eth_stop dev->port_usb=ffffff9b179c3200
--> error happens in usb_ep_enable().
NCM: ncm_disable: ncm=ffffff9b179c3200
--> no gether_disconnect() since ncm->port.in_ep->enabled is false.
NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200
NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
[function link via configfs]
NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000
NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000
NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0
usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm
usb0: eth_start dev->port_usb=ffffff9b179c3200 <--
eth_start_xmit()
--> dev->wrap()
Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at
ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.
It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect
rather than check 'ncm->port.in_ep->enabled' since it might not be enabled
but the gether connection might be established.
CVE-2024-26996
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm: nv04: Fix out of bounds access
When Output Resource (dcb->or) value is assigned in
fabricate_dcb_output(), there may be out of bounds access to
dac_users array in case dcb->or is zero because ffs(dcb->or) is
used as index there.
The 'or' argument of fabricate_dcb_output() must be interpreted as a
number of bit to set, not value.
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-27008
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is
mirrored or redirected to self we hit a qdisc lock deadlock.
See trace below.
[..... other info removed for brevity....]
[ 82.890906]
[ 82.890906] ============================================
[ 82.890906] WARNING: possible recursive locking detected
[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W
[ 82.890906] --------------------------------------------
[ 82.890906] ping/418 is trying to acquire lock:
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[ 82.890906]
[ 82.890906] but task is already holding lock:
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[ 82.890906]
[ 82.890906] other info that might help us debug this:
[ 82.890906] Possible unsafe locking scenario:
[ 82.890906]
[ 82.890906] CPU0
[ 82.890906] ----
[ 82.890906] lock(&sch->q.lock);
[ 82.890906] lock(&sch->q.lock);
[ 82.890906]
[ 82.890906] *** DEADLOCK ***
[ 82.890906]
[..... other info removed for brevity....]
Example setup (eth0->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
action mirred egress redirect dev eth0
Another example(eth0->eth1->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after
root qdisc is entered. When the softirq enters it a second time, if the
qdisc owner is the same CPU, the packet is dropped to break the loop.
CVE-2024-27010
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix memleak in map from abort path
The delete set command does not rely on the transaction object for
element removal, therefore, a combination of delete element + delete set
from the abort path could result in restoring twice the refcount of the
mapping.
Check for inactive element in the next generation for the delete element
command in the abort path, skip restoring state if next generation bit
has been already cleared. This is similar to the activate logic using
the set walk iterator.
[ 6170.286929] ------------[ cut here ]------------
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287071] Modules linked in: [...]
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000
[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10
[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100
[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000
[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0
[ 6170.287962] Call Trace:
[ 6170.287967] <TASK>
[ 6170.287973] ? __warn+0x9f/0x1a0
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092] ? report_bug+0x1b1/0x1e0
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092] ? report_bug+0x1b1/0x1e0
[ 6170.288104] ? handle_bug+0x3c/0x70
[ 6170.288112] ? exc_invalid_op+0x17/0x40
[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20
[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]
CVE-2024-27011
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tun: limit printing rate when illegal packet received by tun dev
vhost_worker will call tun call backs to receive packets. If too many
illegal packets arrives, tun_do_read will keep dumping packet contents.
When console is enabled, it will costs much more cpu time to dump
packet and soft lockup will be detected.
net_ratelimit mechanism can be used to limit the dumping rate.
PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980"
#0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253
#1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3
#2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e
#3 [fffffe00003fced0] do_nmi at ffffffff8922660d
#4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663
[exception RIP: io_serial_in+20]
RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002
RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000
RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0
RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f
R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020
R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#5 [ffffa655314979e8] io_serial_in at ffffffff89792594
#6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470
#7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6
#8 [ffffa65531497a20] uart_console_write at ffffffff8978b605
#9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558
#10 [ffffa65531497ac8] console_unlock at ffffffff89316124
#11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07
#12 [ffffa65531497b68] printk at ffffffff89318306
#13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
#14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]
#15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]
#16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]
#17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
#18 [ffffa65531497f10] kthread at ffffffff892d2e72
#19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f
CVE-2024-27013
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the `priv->state_lock`, any scheduled
aRFS works are canceled using the `cancel_work_sync` function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the `state_lock` which is already acquired.
The worker acquires the lock to delete the rules if the state
is down, which is not the worker's responsibility since
disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is
enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
------------------------------------------------------
ethtool/386089 is trying to acquire lock:
ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock:
ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}:
__mutex_lock+0x80/0xc90
arfs_handle_work+0x4b/0x3b0 [mlx5_core]
process_one_work+0x1dc/0x4a0
worker_thread+0x1bf/0x3c0
kthread+0xd7/0x100
ret_from_fork+0x2d/0x50
ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:
__lock_acquire+0x17b4/0x2c80
lock_acquire+0xd0/0x2b0
__flush_work+0x7a/0x4e0
__cancel_work_timer+0x131/0x1c0
arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0
ethnl_default_set_doit+0xec/0x240
genl_family_rcv_msg_doit+0xd0/0x120
genl_rcv_msg+0x188/0x2c0
netlink_rcv_skb+0x54/0x100
genl_rcv+0x24/0x40
netlink_unicast+0x1a1/0x270
netlink_sendmsg+0x214/0x460
__sock_sendmsg+0x38/0x60
__sys_sendto+0x113/0x170
__x64_sys_sendto+0x20/0x30
do_syscall_64+0x40/0xe0
entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
lock(&priv->state_lock);
lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089:
#0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
#1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
#2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace:
CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x60/0xa0
check_noncircular+0x144/0x160
__lock_acquire+0x17b4/0x2c80
lock_acquire+0xd0/0x2b0
? __flush_work+0x74/0x4e0
? save_trace+0x3e/0x360
? __flush_work+0x74/0x4e0
__flush_work+0x7a/0x4e0
? __flush_work+0x74/0x4e0
? __lock_acquire+0xa78/0x2c80
? lock_acquire+0xd0/0x2b0
? mark_held_locks+0x49/0x70
__cancel_work_timer+0x131/0x1c0
? mark_held_locks+0x49/0x70
arfs_del_rules+0x143/0x1e0 [mlx5_core]
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
ethnl_set_channels+0x28f/0x3b0
ethnl_default_set_doit+0xec/0x240
genl_family_rcv_msg_doit+0xd0/0x120
genl_rcv_msg+0x188/0x2c0
? ethn
---truncated---
CVE-2024-27014
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(),
and there is not any protection when iterate over nf_tables_objects
list in __nft_obj_type_get(). Therefore, there is potential data-race
of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects
list in __nft_obj_type_get(), and use rcu_read_lock() in the caller
nft_obj_type_get() to protect the entire type query process.
CVE-2024-27019
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
nft_unregister_expr() can concurrent with __nft_expr_type_get(),
and there is not any protection when iterate over nf_tables_expressions
list in __nft_expr_type_get(). Therefore, there is potential data-race
of nf_tables_expressions list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
nft_expr_type_get() to protect the entire type query process.
CVE-2024-27020
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nbd: null check for nla_nest_start
nla_nest_start() may fail and return NULL. Insert a check and set errno
based on other call sites within the same source code.
CVE-2024-27025
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: edia: dvbdev: fix a use-after-free
In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:
budget_register
|-> dvb_dmxdev_init
|-> dvb_register_device
|-> dvb_dmxdev_release
|-> dvb_unregister_device
|-> dvb_remove_device
|-> dvb_device_put
|-> kref_put
When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free.
CVE-2024-27043
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nfp: flower: handle acti_netdevs allocation failure
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
the physical memory has run out. As a result, if we dereference
the acti_netdevs, the null pointer dereference bugs will happen.
This patch adds a check to judge whether allocation failure occurs.
If it happens, the delayed work will be rescheduled and try again.
CVE-2024-27046
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-27051
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix double module refcount decrement
Once the discipline is associated with the device, deleting the device
takes care of decrementing the module's refcount. Doing it manually on
this error path causes refcount to artificially decrease on each error
while it should just stay the same.
CVE-2024-27054
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values
in the ATA ID information to calculate cylinder and head values when
creating a CDB for READ or WRITE commands. The calculation involves
division and modulus operations, which will cause a crash if either of
these values is 0. While this never happens with a genuine device, it
could happen with a flawed or subversive emulation, as reported by the
syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if
either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID
information is 0. This requires isd200_Initialization() to return a
negative error code when initialization fails; currently it always
returns 0 (even when there is an error).
CVE-2024-27059
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nouveau: lock the client object tree.
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI
[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]
[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe
[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206
[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58
[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400
[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000
[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0
[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007
[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000
[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0
[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4562.099544] Call Trace:
[ 4562.099555] <TASK>
[ 4562.099573] ? die_addr+0x36/0x90
[ 4562.099583] ? exc_general_protection+0x246/0x4a0
[ 4562.099593] ? asm_exc_general_protection+0x26/0x30
[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]
[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]
[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]
[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]
[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0
[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]
[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270
[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]
[ 4562.100356] __do_fault+0x32/0x150
[ 4562.100362] do_fault+0x7c/0x560
[ 4562.100369] __handle_mm_fault+0x800/0xc10
[ 4562.100382] handle_mm_fault+0x17c/0x3e0
[ 4562.100388] do_user_addr_fault+0x208/0x860
[ 4562.100395] exc_page_fault+0x7f/0x200
[ 4562.100402] asm_exc_page_fault+0x26/0x30
[ 4562.100412] RIP: 0033:0x9b9870
[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7
[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246
[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000
[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066
[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000
[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff
[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 4562.100446] </TASK>
[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink
---truncated---
CVE-2024-27062
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because
are useless and may led to a deadlock as reported here:
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
Also remove usbtv_stop() call since it will be called when
unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you
disconnect while streaming and now it is noticeable even when
disconnecting while not streaming.
[hverkuil: fix minor spelling mistake in log message]
CVE-2024-27072
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
should free the resources it allocates, like the error-handling of
ttpci_budget_init does. Besides, there are two fixme comment refers to
such deallocations.
CVE-2024-27073
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: go7007: fix a memleak in go7007_load_encoder
In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without
a deallocation thereafter. After the following call chain:
saa7134_go7007_init
|-> go7007_boot_encoder
|-> go7007_load_encoder
|-> kfree(go)
go is freed and thus bounce is leaked.
CVE-2024-27074
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: avoid stack overflow warnings with clang
A previous patch worked around a KASAN issue in stv0367, now a similar
problem showed up with clang:
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
Rework the stv0367_writereg() function to be simpler and mark both
register access functions as noinline_for_stack so the temporary
i2c_msg structures do not get duplicated on the stack when KASAN_STACK
is enabled.
CVE-2024-27075
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-tpg: fix some memleaks in tpg_alloc
In tpg_alloc, resources should be deallocated in each and every
error-handling paths, since they are allocated in for statements.
Otherwise there would be memleaks because tpg_free is called only when
tpg_alloc return 0.
CVE-2024-27078
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix some memleaks in gssx_dec_option_array
The creds and oa->data need to be freed in the error-handling paths after
their allocation. So this patch add these deallocations in the
corresponding paths.
CVE-2024-27388
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: gtp: Fix Use-After-Free in gtp_dellink
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
of gtp_dellink, is not part of the RCU read critical section, it
is possible that the RCU grace period will pass during the traversal and
the key will be free.
To prevent this, it should be changed to hlist_for_each_entry_safe.
CVE-2024-27396
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
When the sco connection is established and then, the sco socket
is releasing, timeout_work will be scheduled to judge whether
the sco disconnection is timeout. The sock will be deallocated
later, but it is dereferenced again in sco_sock_timeout. As a
result, the use-after-free bugs will happen. The root cause is
shown below:
Cleanup Thread | Worker Thread
sco_sock_release |
sco_sock_close |
__sco_sock_close |
sco_sock_set_timer |
schedule_delayed_work |
sco_sock_kill | (wait a time)
sock_put(sk) //FREE | sco_sock_timeout
| sock_hold(sk) //USE
The KASAN report triggered by POC is shown below:
[ 95.890016] ==================================================================
[ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
[ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
...
[ 95.890755] Workqueue: events sco_sock_timeout
[ 95.890755] Call Trace:
[ 95.890755] <TASK>
[ 95.890755] dump_stack_lvl+0x45/0x110
[ 95.890755] print_address_description+0x78/0x390
[ 95.890755] print_report+0x11b/0x250
[ 95.890755] ? __virt_addr_valid+0xbe/0xf0
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
[ 95.890755] kasan_report+0x139/0x170
[ 95.890755] ? update_load_avg+0xe5/0x9f0
[ 95.890755] ? sco_sock_timeout+0x5e/0x1c0
[ 95.890755] kasan_check_range+0x2c3/0x2e0
[ 95.890755] sco_sock_timeout+0x5e/0x1c0
[ 95.890755] process_one_work+0x561/0xc50
[ 95.890755] worker_thread+0xab2/0x13c0
[ 95.890755] ? pr_cont_work+0x490/0x490
[ 95.890755] kthread+0x279/0x300
[ 95.890755] ? pr_cont_work+0x490/0x490
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
[ 95.890755] ret_from_fork+0x34/0x60
[ 95.890755] ? kthread_blkcg+0xa0/0xa0
[ 95.890755] ret_from_fork_asm+0x11/0x20
[ 95.890755] </TASK>
[ 95.890755]
[ 95.890755] Allocated by task 506:
[ 95.890755] kasan_save_track+0x3f/0x70
[ 95.890755] __kasan_kmalloc+0x86/0x90
[ 95.890755] __kmalloc+0x17f/0x360
[ 95.890755] sk_prot_alloc+0xe1/0x1a0
[ 95.890755] sk_alloc+0x31/0x4e0
[ 95.890755] bt_sock_alloc+0x2b/0x2a0
[ 95.890755] sco_sock_create+0xad/0x320
[ 95.890755] bt_sock_create+0x145/0x320
[ 95.890755] __sock_create+0x2e1/0x650
[ 95.890755] __sys_socket+0xd0/0x280
[ 95.890755] __x64_sys_socket+0x75/0x80
[ 95.890755] do_syscall_64+0xc4/0x1b0
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
[ 95.890755]
[ 95.890755] Freed by task 506:
[ 95.890755] kasan_save_track+0x3f/0x70
[ 95.890755] kasan_save_free_info+0x40/0x50
[ 95.890755] poison_slab_object+0x118/0x180
[ 95.890755] __kasan_slab_free+0x12/0x30
[ 95.890755] kfree+0xb2/0x240
[ 95.890755] __sk_destruct+0x317/0x410
[ 95.890755] sco_sock_release+0x232/0x280
[ 95.890755] sock_close+0xb2/0x210
[ 95.890755] __fput+0x37f/0x770
[ 95.890755] task_work_run+0x1ae/0x210
[ 95.890755] get_signal+0xe17/0xf70
[ 95.890755] arch_do_signal_or_restart+0x3f/0x520
[ 95.890755] syscall_exit_to_user_mode+0x55/0x120
[ 95.890755] do_syscall_64+0xd1/0x1b0
[ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f
[ 95.890755]
[ 95.890755] The buggy address belongs to the object at ffff88800c388000
[ 95.890755] which belongs to the cache kmalloc-1k of size 1024
[ 95.890755] The buggy address is located 128 bytes inside of
[ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)
[ 95.890755]
[ 95.890755] The buggy address belongs to the physical page:
[ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
[ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[ 95.890755] ano
---truncated---
CVE-2024-27398
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
There is a race condition between l2cap_chan_timeout() and
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
channel, the chan->conn will be set to null. But the conn could
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
As a result the null pointer dereference bug will happen. The
KASAN report triggered by POC is shown below:
[ 472.074580] ==================================================================
[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
[ 472.075308]
[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
[ 472.075308] Workqueue: events l2cap_chan_timeout
[ 472.075308] Call Trace:
[ 472.075308] <TASK>
[ 472.075308] dump_stack_lvl+0x137/0x1a0
[ 472.075308] print_report+0x101/0x250
[ 472.075308] ? __virt_addr_valid+0x77/0x160
[ 472.075308] ? mutex_lock+0x68/0xc0
[ 472.075308] kasan_report+0x139/0x170
[ 472.075308] ? mutex_lock+0x68/0xc0
[ 472.075308] kasan_check_range+0x2c3/0x2e0
[ 472.075308] mutex_lock+0x68/0xc0
[ 472.075308] l2cap_chan_timeout+0x181/0x300
[ 472.075308] process_one_work+0x5d2/0xe00
[ 472.075308] worker_thread+0xe1d/0x1660
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
[ 472.075308] kthread+0x2b7/0x350
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
[ 472.075308] ret_from_fork+0x4d/0x80
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
[ 472.075308] ret_from_fork_asm+0x11/0x20
[ 472.075308] </TASK>
[ 472.075308] ==================================================================
[ 472.094860] Disabling lock debugging due to kernel taint
[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
[ 472.096136] #PF: supervisor write access in kernel mode
[ 472.096136] #PF: error_code(0x0002) - not-present page
[ 472.096136] PGD 0 P4D 0
[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36
[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
[ 472.096136] Workqueue: events l2cap_chan_timeout
[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0
[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
[ 472.096136] Call Trace:
[ 472.096136] <TASK>
[ 472.096136] ? __die_body+0x8d/0xe0
[ 472.096136] ? page_fault_oops+0x6b8/0x9a0
[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0
[ 472.096136] ? do_user_addr_fault+0x1027/0x1340
[ 472.096136] ? _printk+0x7a/0xa0
[ 472.096136] ? mutex_lock+0x68/0xc0
[ 472.096136] ? add_taint+0x42/0xd0
[ 472.096136] ? exc_page_fault+0x6a/0x1b0
[ 472.096136] ? asm_exc_page_fault+0x26/0x30
[ 472.096136] ? mutex_lock+0x75/0xc0
[ 472.096136] ? mutex_lock+0x88/0xc0
[ 472.096136] ? mutex_lock+0x75/0xc0
[ 472.096136] l2cap_chan_timeo
---truncated---
CVE-2024-27399
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firewire: nosy: ensure user_length is taken into account when fetching packet contents
Ensure that packet_buffer_get respects the user_length provided. If
the length of the head packet exceeds the user_length, packet_buffer_get
will now return 0 to signify to the user that no data were read
and a larger buffer size is required. Helps prevent user space overflows.
CVE-2024-27401
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: reject iftype change with mesh ID change
It's currently possible to change the mesh ID when the
interface isn't yet in mesh mode, at the same time as
changing it into mesh mode. This leads to an overwrite
of data in the wdev->u union for the interface type it
currently has, causing cfg80211_change_iface() to do
wrong things when switching.
We could probably allow setting an interface to mesh
while setting the mesh ID at the same time by doing a
different order of operations here, but realistically
there's no userspace that's going to do this, so just
disallow changes in iftype when setting mesh ID.
CVE-2024-27410
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Stop parsing channels bits when all channels are found.
If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.
CVE-2024-27436
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Disable auto-enable of exclusive INTx IRQ
Currently for devices requiring masking at the irqchip for INTx, ie.
devices without DisINTx support, the IRQ is enabled in request_irq()
and subsequently disabled as necessary to align with the masked status
flag. This presents a window where the interrupt could fire between
these events, resulting in the IRQ incrementing the disable depth twice.
This would be unrecoverable for a user since the masked flag prevents
nested enables through vfio.
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
is never auto-enabled, then unmask as required.
CVE-2024-27437
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
wall in util-linux through 2.40, often installed with setgid tty permissions, allows escape sequences to be sent to other users' terminals through argv. (Specifically, escape sequences received from stdin are blocked, but escape sequences received from argv are not blocked.) There may be plausible scenarios where this leads to account takeover.
CVE-2024-28085
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libblkid1-2.33.2-4.45.2
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libfdisk1-2.33.2-4.45.2
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libmount1-2.33.2-4.45.2
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libsmartcols1-2.33.2-4.45.2
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libuuid1-2.33.2-4.45.2
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:util-linux-2.33.2-4.45.2
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:util-linux-systemd-2.33.2-4.45.2
important
nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. The nghttp2 library prior to version 1.61.0 keeps reading the unbounded number of HTTP/2 CONTINUATION frames even after a stream is reset to keep HPACK context in sync. This causes excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0 mitigates this vulnerability by limiting the number of CONTINUATION frames it accepts per stream. There is no workaround for this vulnerability.
CVE-2024-28182
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libnghttp2-14-1.39.2-3.18.1
important
libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate).
CVE-2024-28757
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
CVE-2024-28956
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
The iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable.
CVE-2024-2961
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-i18ndata-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-locale-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:nscd-2.22-114.40.1
important
less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.
CVE-2024-32487
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:less-458-7.15.1
important
nscd: Stack-based buffer overflow in netgroup cache
If the Name Service Cache Daemon's (nscd) fixed size cache is exhausted
by client requests then a subsequent client request for netgroup data
may result in a stack-based buffer overflow. This flaw was introduced
in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
CVE-2024-33599
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-i18ndata-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-locale-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:nscd-2.22-114.40.1
important
nscd: Null pointer crashes after notfound response
If the Name Service Cache Daemon's (nscd) cache fails to add a not-found
netgroup response to the cache, the client request can result in a null
pointer dereference. This flaw was introduced in glibc 2.15 when the
cache was added to nscd.
This vulnerability is only present in the nscd binary.
CVE-2024-33600
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-i18ndata-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-locale-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:nscd-2.22-114.40.1
important
nscd: netgroup cache may terminate daemon on memory allocation failure
The Name Service Cache Daemon's (nscd) netgroup cache uses xmalloc or
xrealloc and these functions may terminate the process due to a memory
allocation failure resulting in a denial of service to the clients. The
flaw was introduced in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
CVE-2024-33601
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-i18ndata-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-locale-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:nscd-2.22-114.40.1
moderate
nscd: netgroup cache assumes NSS callback uses in-buffer strings
The Name Service Cache Daemon's (nscd) netgroup cache can corrupt memory
when the NSS callback does not store all strings in the provided buffer.
The flaw was introduced in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
CVE-2024-33602
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-i18ndata-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-locale-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:nscd-2.22-114.40.1
moderate
An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.
CVE-2024-34397
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
low
An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.
CVE-2024-34459
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
low
Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.
CVE-2024-35195
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-requests-2.24.0-8.23.1
moderate
OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be world writable. Given the aforementioned Ubuntu AppArmor context, on such systems this vulnerability is limited to those files modifiable by the cupsd process. In that specific case it was found to be possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the issue.
CVE-2024-35235
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:cups-libs-1.7.5-20.57.1
important
In the Linux kernel, the following vulnerability has been resolved:
fpga: region: add owner module and take its refcount
The current implementation of the fpga region assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the region
during programming if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_region
struct and use it to take the module's refcount. Modify the functions for
registering a region to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the region as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a region without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga region.
CVE-2024-35247
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
When moving a station out of a VLAN and deleting the VLAN afterwards, the
fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
after the VLAN change.
CVE-2024-35789
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
The DisplayPort driver's sysfs nodes may be present to the userspace before
typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that
a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in
hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns
NULL in those cases.
Remove manual sysfs node creation in favor of adding attribute group as
default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is
not used here otherwise the path to the sysfs nodes is no longer compliant
with the ABI.
CVE-2024-35790
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
Do the cache flush of converted pages in svm_register_enc_region() before
dropping kvm->lock to fix use-after-free issues where region and/or its
array of pages could be freed by a different task, e.g. if userspace has
__unregister_enc_region_locked() already queued up for the region.
Note, the "obvious" alternative of using local variables doesn't fully
resolve the bug, as region->pages is also dynamically allocated. I.e. the
region structure itself would be fine, but region->pages could be freed.
Flushing multiple pages under kvm->lock is unfortunate, but the entire
flow is a rare slow path, and the manual flush is only needed on CPUs that
lack coherency for encrypted memory.
CVE-2024-35791
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm snapshot: fix lockup in dm_exception_table_exit
There was reported lockup when we exit a snapshot with many exceptions.
Fix this by adding "cond_resched" to the loop that frees the exceptions.
CVE-2024-35805
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix corruption during on-line resize
We observed a corruption during on-line resize of a file system that is
larger than 16 TiB with 4k block size. With having more then 2^32 blocks
resize_inode is turned off by default by mke2fs. The issue can be
reproduced on a smaller file system for convenience by explicitly
turning off resize_inode. An on-line resize across an 8 GiB boundary (the
size of a meta block group in this setup) then leads to a corruption:
dev=/dev/<some_dev> # should be >= 16 GiB
mkdir -p /corruption
/sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))
mount -t ext4 $dev /corruption
dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))
sha1sum /corruption/test
# 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test
/sbin/resize2fs $dev $((2*2**21))
# drop page cache to force reload the block from disk
echo 1 > /proc/sys/vm/drop_caches
sha1sum /corruption/test
# 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test
2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per
block group and 2^6 are the number of block groups that make a meta
block group.
The last checksum might be different depending on how the file is laid
out across the physical blocks. The actual corruption occurs at physical
block 63*2^15 = 2064384 which would be the location of the backup of the
meta block group's block descriptor. During the on-line resize the file
system will be converted to meta_bg starting at s_first_meta_bg which is
2 in the example - meaning all block groups after 16 GiB. However, in
ext4_flex_group_add we might add block groups that are not part of the
first meta block group yet. In the reproducer we achieved this by
substracting the size of a whole block group from the point where the
meta block group would start. This must be considered when updating the
backup block group descriptors to follow the non-meta_bg layout. The fix
is to add a test whether the group to add is already part of the meta
block group or not.
CVE-2024-35807
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI/PM: Drain runtime-idle callbacks before driver removal
A race condition between the .runtime_idle() callback and the .remove()
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
unhandled page fault [1].
The problem is that rtsx_pci_runtime_idle() is not expected to be running
after pm_runtime_get_sync() has been called, but the latter doesn't really
guarantee that. It only guarantees that the suspend and resume callbacks
will not be running when it returns.
However, if a .runtime_idle() callback is already running when
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
status of the device is RPM_ACTIVE and it will return right away without
waiting for the former to complete. In fact, it cannot wait for
.runtime_idle() to complete because it may be called from that callback (it
arguably does not make much sense to do that, but it is not strictly
prohibited).
Thus in general, whoever is providing a .runtime_idle() callback needs
to protect it from running in parallel with whatever code runs after
pm_runtime_get_sync(). [Note that .runtime_idle() will not start after
pm_runtime_get_sync() has returned, but it may continue running then if it
has started earlier.]
One way to address that race condition is to call pm_runtime_barrier()
after pm_runtime_get_sync() (not before it, because a nonzero value of the
runtime PM usage counter is necessary to prevent runtime PM callbacks from
being invoked) to wait for the .runtime_idle() callback to complete should
it be running at that point. A suitable place for doing that is in
pci_device_remove() which calls pm_runtime_get_sync() before removing the
driver, so it may as well call pm_runtime_barrier() subsequently, which
will prevent the race in question from occurring, not just in the rtsx_pcr
driver, but in any PCI drivers providing .runtime_idle() callbacks.
CVE-2024-35809
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until
commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
which invokes smp_call_function_single via qman_update_cgr_safe every
time a link goes up or down.
CVE-2024-35819
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: udc: remove warning when queue disabled ep
It is possible trigger below warning message from mass storage function,
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
pc : usb_ep_queue+0x7c/0x104
lr : fsg_main_thread+0x494/0x1b3c
Root cause is mass storage function try to queue request from main thread,
but other thread may already disable ep when function disable.
As there is no function failure in the driver, in order to avoid effort
to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().
CVE-2024-35822
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().
CVE-2024-35828
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: tc358743: register v4l2 async device only after successful setup
Ensure the device has been setup correctly before registering the v4l2
async device, thus allowing userspace to access.
CVE-2024-35830
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a double-free in arfs_create_groups
When `in` allocated by kvzalloc fails, arfs_create_groups will free
ft->g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft->g will be freed again.
CVE-2024-35835
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: clear BM pool before initialization
Register value persist after booting the kernel using
kexec which results in kernel panic. Thus clear the
BM pool registers before initialisation to fix the issue.
CVE-2024-35837
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: replace physindev with physinif in nf_bridge_info
An skb can be added to a neigh->arp_queue while waiting for an arp
reply. Where original skb's skb->dev can be different to neigh's
neigh->dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh->arp_queue of the bridge.
As skb->dev can be reset back to nf_bridge->physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
different device's neigh queue) we can crash on e.g. this stack:
arp_process
neigh_update
skb = __skb_dequeue(&neigh->arp_queue)
neigh_resolve_output(..., skb)
...
br_nf_dev_xmit
br_nf_pre_routing_finish_bridge_slow
skb->dev = nf_bridge->physindev
br_handle_frame_finish
Let's use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don't get it and drop skb.
CVE-2024-35839
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
Syzbot reported the following information leak for in
btrfs_ioctl_logical_to_ino():
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
copy_to_user include/linux/uaccess.h:191 [inline]
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
btrfs_ioctl+0x714/0x1260
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
__do_kmalloc_node mm/slub.c:3954 [inline]
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
kmalloc_node include/linux/slab.h:648 [inline]
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
kvmalloc include/linux/slab.h:766 [inline]
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
btrfs_ioctl+0x714/0x1260
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Bytes 40-65535 of 65536 are uninitialized
Memory access of size 65536 starts at ffff888045a40000
This happens, because we're copying a 'struct btrfs_data_container' back
to user-space. This btrfs_data_container is allocated in
'init_data_container()' via kvmalloc(), which does not zero-fill the
memory.
Fix this by using kvzalloc() which zeroes out the memory on allocation.
CVE-2024-35849
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_is_network_name_deleted()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
CVE-2024-35862
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in is_valid_oplock_break()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
CVE-2024-35863
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_is_valid_lease_break()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
CVE-2024-35864
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2_is_valid_oplock_break()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
CVE-2024-35865
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_stats_proc_show()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
CVE-2024-35867
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in cifs_stats_proc_write()
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
CVE-2024-35868
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that
is already being teared down by another thread that is executing
__cifs_put_smb_ses(). This can happen when (a) the client has
connection to the server but no session or (b) another thread ends up
setting @ses->ses_status again to something different than
SES_EXITING.
To fix this, we need to make sure to unconditionally set
@ses->ses_status to SES_EXITING and prevent any other threads from
setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after
the ipc is freed in __cifs_put_smb_ses() - which will give
smb2_reconnect_server() worker a chance to run and then accessing
@ses->ipc:
kinit ...
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
[disconnect srv]
ls /mnt/1 &>/dev/null
sleep 30
kdestroy
[reconnect srv]
sleep 10
umount /mnt/1
...
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
04/01/2014
Workqueue: cifsiod smb2_reconnect_server [cifs]
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? die_addr+0x36/0x90
? exc_general_protection+0x1c1/0x3f0
? asm_exc_general_protection+0x26/0x30
? __list_del_entry_valid_or_report+0x33/0xf0
__cifs_put_smb_ses+0x1ae/0x500 [cifs]
smb2_reconnect_server+0x4ed/0x710 [cifs]
process_one_work+0x205/0x6b0
worker_thread+0x191/0x360
? __pfx_worker_thread+0x10/0x10
kthread+0xe2/0x110
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
CVE-2024-35870
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or,
in fact, all PTEs) can be replaced during write faults to point at anon
folios. Reliably recovering the correct PFN and cachemode using
follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon
folio (which is very wrong), or fail on swap/nonswap entries, failing
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call
it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we
don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if
the first page was replaced by an anon folio, though: we'd have to store
the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that
case: it would have failed in the past with swap/nonswap entries already,
and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer --->
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
#include <liburing.h>
int main(void)
{
struct io_uring_params p = {};
int ring_fd;
size_t size;
char *map;
ring_fd = io_uring_setup(1, &p);
if (ring_fd < 0) {
perror("io_uring_setup");
return 1;
}
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
/* Map the submission queue ring MAP_PRIVATE */
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
ring_fd, IORING_OFF_SQ_RING);
if (map == MAP_FAILED) {
perror("mmap");
return 1;
}
/* We have at least one page. Let's COW it. */
*map = 0;
pause();
return 0;
}
<--- C reproducer --->
On a system with 16 GiB RAM and swap configured:
# ./iouring &
# memhog 16G
# killall iouring
[ 301.552930] ------------[ cut here ]------------
[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
[ 301.565725] PKRU: 55555554
[ 301.565944] Call Trace:
[ 301.566148] <TASK>
[ 301.566325] ? untrack_pfn+0xf4/0x100
[ 301.566618] ? __warn+0x81/0x130
[ 301.566876] ? untrack_pfn+0xf4/0x100
[ 3
---truncated---
CVE-2024-35877
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
of: module: prevent NULL pointer dereference in vsnprintf()
In of_modalias(), we can get passed the str and len parameters which would
cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr
when the length is also 0. Also, we need to filter out the negative values
of the len parameter as these will result in a really huge buffer since
snprintf() takes size_t parameter while ours is ssize_t...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
CVE-2024-35878
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during
netlink socket destruction. [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
the response was generated. The following recvmmsg() resumed the dump
for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
to the fault injection. [0]
12:01:34 executing program 3:
r0 = socket$nl_route(0x10, 0x3, 0x0)
sendmsg$nl_route(r0, ... snip ...)
recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call
of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped
receiving the response halfway through, and finally netlink_sock_destruct()
called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it
is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by
nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling
itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:117)
should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
should_failslab (mm/slub.c:3733)
kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)
inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)
rtnl_dump_all (net/core/rtnetlink.c:4029)
netlink_dump (net/netlink/af_netlink.c:2269)
netlink_recvmsg (net/netlink/af_netlink.c:1988)
____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)
___sys_recvmsg (net/socket.c:2846)
do_recvmmsg (net/socket.c:2943)
__x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
[1]:
BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)
stack guard page: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)
Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff
RSP: 0018:ffffc9000d980000 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3
RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358
RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000
R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68
FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
<#DF>
</#DF>
<TASK>
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
...
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
netlink_sock_destruct (net/netlink/af_netlink.c:401)
__sk_destruct (net/core/sock.c:2177 (discriminator 2))
sk_destruct (net/core/sock.c:2224)
__sk_free (net/core/sock.c:2235)
sk_free (net/core/sock.c:2246)
process_one_work (kernel/workqueue.c:3259)
worker_thread (kernel/workqueue.c:3329 kernel/workqueue.
---truncated---
CVE-2024-35886
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
When the ax25 device is detaching, the ax25_dev_device_down()
calls ax25_ds_del_timer() to cleanup the slave_timer. When
the timer handler is running, the ax25_ds_del_timer() that
calls del_timer() in it will return directly. As a result,
the use-after-free bugs could happen, one of the scenarios
is shown below:
(Thread 1) | (Thread 2)
| ax25_ds_timeout()
ax25_dev_device_down() |
ax25_ds_del_timer() |
del_timer() |
ax25_dev_put() //FREE |
| ax25_dev-> //USE
In order to mitigate bugs, when the device is detaching, use
timer_shutdown_sync() to stop the timer.
CVE-2024-35887
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_skbmod: prevent kernel-infoleak
syzbot found that tcf_skbmod_dump() was copying four bytes
from kernel stack to user space [1].
The issue here is that 'struct tc_skbmod' has a four bytes hole.
We need to clear the structure before filling fields.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
copy_to_user_iter lib/iov_iter.c:24 [inline]
iterate_ubuf include/linux/iov_iter.h:29 [inline]
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
iterate_and_advance include/linux/iov_iter.h:271 [inline]
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
copy_to_iter include/linux/uio.h:196 [inline]
simple_copy_to_iter net/core/datagram.c:532 [inline]
__skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
sock_recvmsg_nosec net/socket.c:1046 [inline]
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
__sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
__do_sys_recvfrom net/socket.c:2260 [inline]
__se_sys_recvfrom net/socket.c:2256 [inline]
__x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was stored to memory at:
pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
nlmsg_unicast include/net/netlink.h:1144 [inline]
nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
tcf_add_notify net/sched/act_api.c:2048 [inline]
tcf_action_add net/sched/act_api.c:2071 [inline]
tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was stored to memory at:
__nla_put lib/nlattr.c:1041 [inline]
nla_put+0x1c6/0x230 lib/nlattr.c:1099
tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
tcf_action_dump_old net/sched/act_api.c:1191 [inline]
tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
tcf_add_notify net/sched/act_api.c:2042 [inline]
tcf_action_add net/sched/act_api.c:2071 [inline]
tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
---truncated---
CVE-2024-35893
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account
before copying data.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
__asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
copy_from_sockptr include/linux/sockptr.h:55 [inline]
do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x72/0x7a
RIP: 0033:0x7fd22067dde9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
</TASK>
Allocated by task 7238:
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:370 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
kasan_kmalloc include/linux/kasan.h:211 [inline]
__do_kmalloc_node mm/slub.c:4069 [inline]
__kmalloc_noprof+0x200/0x410 mm/slub.c:4082
kmalloc_noprof include/linux/slab.h:664 [inline]
__cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00
---truncated---
CVE-2024-35896
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after
the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often,
and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context,
including when socket lock is held.
This is the reason it uses sk_stop_timer(), aka del_timer().
This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer
holds a reference on the socket, and the user socket holds
a reference on the netns.
For kernel sockets, we risk that the netns is freed before
timer can complete, because kernel sockets do not hold
reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function
that using sk_stop_timer_sync() to make sure all timers
are terminated before the kernel socket is released.
Modules using kernel sockets close them in their netns exit()
handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP
support : inet_csk_clear_xmit_timers_sync() must not be called
while socket lock is held.
It is very possible we can revert in the future commit
3a58f13a881e ("net: rds: acquire refcount on TCP sockets")
which attempted to solve the issue in rds only.
(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from
tcp_out_of_resources() and __tcp_close() in the future.
CVE-2024-35910
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue [1][2]:
nci_rx_work() parses and processes received packet. When the payload
length is zero, each message type handler reads uninitialized payload
and KMSAN detects this issue. The receipt of a packet with a zero-size
payload is considered unexpected, and therefore, such packets should be
silently discarded.
This patch resolved this issue by checking payload size before calling
each message type handler codes.
CVE-2024-35915
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on
overflow. It is necessary to prevent division by zero like in
fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.
CVE-2024-35922
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst->nr_samples + src->nr_samples may
have zero value on overflow. It is necessary to add
a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.
CVE-2024-35925
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
unsuccessful status. In such cases, the elsiocb is not issued, the
completion is not called, and thus the elsiocb resource is leaked.
Check return value after calling lpfc_sli4_resume_rpi() and conditionally
release the elsiocb resource.
CVE-2024-35930
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: don't check if plane->state->fb == state->fb
Currently, when using non-blocking commits, we can see the following
kernel warning:
[ 110.908514] ------------[ cut here ]------------
[ 110.908529] refcount_t: underflow; use-after-free.
[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0
[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32
[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0
[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0
[ 110.909170] sp : ffffffc00913b9c0
[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60
[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480
[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78
[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000
[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004
[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003
[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00
[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572
[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000
[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001
[ 110.909434] Call trace:
[ 110.909441] refcount_dec_not_one+0xb8/0xc0
[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]
[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]
[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]
[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]
[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]
[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]
[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]
[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]
[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]
[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]
[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4
[ 110.914873] invoke_syscall+0x4c/0x114
[ 110.914897] el0_svc_common+0xd0/0x118
[ 110.914917] do_el0_svc+0x38/0xd0
[ 110.914936] el0_svc+0x30/0x8c
[ 110.914958] el0t_64_sync_handler+0x84/0xf0
[ 110.914979] el0t_64_sync+0x18c/0x190
[ 110.914996] ---[ end trace 0000000000000000 ]---
This happens because, although `prepare_fb` and `cleanup_fb` are
perfectly balanced, we cannot guarantee consistency in the check
plane->state->fb == state->fb. This means that sometimes we can increase
the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The
opposite can also be true.
In fact, the struct drm_plane .state shouldn't be accessed directly
but instead, the `drm_atomic_get_new_plane_state()` helper function should
be used. So, we could stick to this check, but using
`drm_atomic_get_new_plane_state()`. But actually, this check is not re
---truncated---
CVE-2024-35932
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel: Fix null ptr deref in btintel_read_version
If hci_cmd_sync_complete() is triggered and skb is NULL, then
hdev->req_skb is NULL, which will cause this issue.
CVE-2024-35933
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: handle path ref underflow in header iterate_inode_ref()
Change BUG_ON to proper error handling if building the path buffer
fails. The pointers are not printed so we don't accidentally leak kernel
addresses.
CVE-2024-35935
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
as it could be caused only by two impossible conditions:
- at first the search key is set up to look for a chunk tree item, with
offset -1, this is an inexact search and the key->offset will contain
the correct offset upon a successful search, a valid chunk tree item
cannot have an offset -1
- after first successful search, the found_key corresponds to a chunk
item, the offset is decremented by 1 before the next loop, it's
impossible to find a chunk item there due to alignment and size
constraints
CVE-2024-35936
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU
but the header isn't fully there, we can end up reading
data out of bounds, only to discard later. Make this a
bit more careful and check if the subframe header can
even be present.
CVE-2024-35937
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.
memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg"
at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)
WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237
dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237
Some code commentry, based on my understanding:
544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size)
/// This is 24 + payload_size
memcpy(&dg_info->msg, dg, dg_size);
Destination = dg_info->msg ---> this is a 24 byte
structure(struct vmci_datagram)
Source = dg --> this is a 24 byte structure (struct vmci_datagram)
Size = dg_size = 24 + payload_size
{payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.
35 struct delayed_datagram_info {
36 struct datagram_entry *entry;
37 struct work_struct work;
38 bool in_dg_host_queue;
39 /* msg and msg_payload must be together. */
40 struct vmci_datagram msg;
41 u8 msg_payload[];
42 };
So those extra bytes of payload are copied into msg_payload[], a run time
warning is seen while fuzzing with Syzkaller.
One possible way to fix the warning is to split the memcpy() into
two parts -- one -- direct assignment of msg and second taking care of payload.
Gustavo quoted:
"Under FORTIFY_SOURCE we should not copy data across multiple members
in a structure."
CVE-2024-35944
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in >control parser
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't
really look), lets make sure by removing it, doing pr_err and return
-EINVAL instead.
CVE-2024-35947
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: make sure that WRITTEN is set on all metadata blocks
We previously would call btrfs_check_leaf() if we had the check
integrity code enabled, which meant that we could only run the extended
leaf checks if we had WRITTEN set on the header flags.
This leaves a gap in our checking, because we could end up with
corruption on disk where WRITTEN isn't set on the leaf, and then the
extended leaf checks don't get run which we rely on to validate all of
the item pointers to make sure we don't access memory outside of the
extent buffer.
However, since 732fab95abe2 ("btrfs: check-integrity: remove
CONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer call
btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only
ever call it on blocks that are being written out, and thus have WRITTEN
set, or that are being read in, which should have WRITTEN set.
Add checks to make sure we have WRITTEN set appropriately, and then make
sure __btrfs_check_leaf() always does the item checking. This will
protect us from file systems that have been corrupted and no longer have
WRITTEN set on some of the blocks.
This was hit on a crafted image tweaking the WRITTEN bit and reported by
KASAN as out-of-bound access in the eb accessors. The example is a dir
item at the end of an eb.
[2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2
[2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI
[2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f]
[2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1
[2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0
[2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206
[2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0
[2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748
[2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9
[2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a
[2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8
[2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000
[2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0
[2.621] Call Trace:
[2.621] <TASK>
[2.621] ? show_regs+0x74/0x80
[2.621] ? die_addr+0x46/0xc0
[2.621] ? exc_general_protection+0x161/0x2a0
[2.621] ? asm_exc_general_protection+0x26/0x30
[2.621] ? btrfs_get_16+0x33a/0x6d0
[2.621] ? btrfs_get_16+0x34b/0x6d0
[2.621] ? btrfs_get_16+0x33a/0x6d0
[2.621] ? __pfx_btrfs_get_16+0x10/0x10
[2.621] ? __pfx_mutex_unlock+0x10/0x10
[2.621] btrfs_match_dir_item_name+0x101/0x1a0
[2.621] btrfs_lookup_dir_item+0x1f3/0x280
[2.621] ? __pfx_btrfs_lookup_dir_item+0x10/0x10
[2.621] btrfs_get_tree+0xd25/0x1910
[ copy more details from report ]
CVE-2024-35949
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev->mode_config.mutex
The modes[] array contains pointers to modes on the connectors'
mode lists, which are protected by dev->mode_config.mutex.
Thus we need to extend modes[] the same protection or by the
time we use it the elements may already be pointing to
freed/reused memory.
CVE-2024-35950
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix possible use-after-free issue on kprobe registration
When unloading a module, its state is changing MODULE_STATE_LIVE ->
MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take
a time. `is_module_text_address()` and `__module_text_address()`
works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
If we use `is_module_text_address()` and `__module_text_address()`
separately, there is a chance that the first one is succeeded but the
next one is failed because module->state becomes MODULE_STATE_UNFORMED
between those operations.
In `check_kprobe_address_safe()`, if the second `__module_text_address()`
is failed, that is ignored because it expected a kernel_text address.
But it may have failed simply because module->state has been changed
to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify
non-exist module text address (use-after-free).
To fix this problem, we should not use separated `is_module_text_address()`
and `__module_text_address()`, but use only `__module_text_address()`
once and do `try_module_get(module)` which is only available with
MODULE_STATE_LIVE.
CVE-2024-35955
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ena: Fix incorrect descriptor free behavior
ENA has two types of TX queues:
- queues which only process TX packets arriving from the network stack
- queues which only process TX packets forwarded to it by XDP_REDIRECT
or XDP_TX instructions
The ena_free_tx_bufs() cycles through all descriptors in a TX queue
and unmaps + frees every descriptor that hasn't been acknowledged yet
by the device (uncompleted TX transactions).
The function assumes that the processed TX queue is necessarily from
the first category listed above and ends up using napi_consume_skb()
for descriptors belonging to an XDP specific queue.
This patch solves a bug in which, in case of a VF reset, the
descriptors aren't freed correctly, leading to crashes.
CVE-2024-35958
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the
handle into the tree when they had a refcount of 1. On the other hand,
create_flow_handle tries hard to find and reference already existing
identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle
1) creates a new rule and references it, then
2) in a subsequent step during the same handle creation references it
again,
resulting in a rule with a refcount of 2 that is not linked into the
tree, will have a NULL parent and root and will result in a crash when
the flow group is deleted because del_sw_hw_rule, invoked on rule
deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect
handling of duplicate pkt_reformat ids, which lead to the code in
create_flow_handle incorrectly referencing a just-added rule in the same
flow handle, resulting in the problem described above. Full details are
at [1].
This patch changes add_rule_fg to add new rules without parents into
the tree, properly initializing them and avoiding the crash. This makes
it more consistent with how rules are added to an FTE in
create_flow_handle.
CVE-2024-35960
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix not validating setsockopt user input
Check user input length before copying data.
CVE-2024-35965
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Fix not validating setsockopt user input
syzbot reported rfcomm_sock_setsockopt_old() is copying data without
checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old
net/bluetooth/rfcomm/sock.c:632 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70
net/bluetooth/rfcomm/sock.c:673
Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064
CVE-2024-35966
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
still means hlist_for_each_entry_rcu can return an item that got removed
from the list. The memory itself of such item is not freed thanks to RCU
but nothing guarantees the actual content of the memory is sane.
In particular, the reference count can be zero. This can happen if
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
timing, this can happen:
1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
2. Then, the whole ipv6_del_addr is executed for the given entry. The
reference count drops to zero and kfree_rcu is scheduled.
3. ipv6_get_ifaddr continues and tries to increments the reference count
(in6_ifa_hold).
4. The rcu is unlocked and the entry is freed.
5. The freed entry is returned.
Prevent increasing of the reference count in such case. The name
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
[ 41.506330] refcount_t: addition on 0; use-after-free.
[ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
[ 41.507413] Modules linked in: veth bridge stp llc
[ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
[ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
[ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
[ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
[ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
[ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
[ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
[ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
[ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
[ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
[ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
[ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 41.516799] Call Trace:
[ 41.517037] <TASK>
[ 41.517249] ? __warn+0x7b/0x120
[ 41.517535] ? refcount_warn_saturate+0xa5/0x130
[ 41.517923] ? report_bug+0x164/0x190
[ 41.518240] ? handle_bug+0x3d/0x70
[ 41.518541] ? exc_invalid_op+0x17/0x70
[ 41.520972] ? asm_exc_invalid_op+0x1a/0x20
[ 41.521325] ? refcount_warn_saturate+0xa5/0x130
[ 41.521708] ipv6_get_ifaddr+0xda/0xe0
[ 41.522035] inet6_rtm_getaddr+0x342/0x3f0
[ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10
[ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0
[ 41.523102] ? netlink_unicast+0x30f/0x390
[ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[ 41.523832] netlink_rcv_skb+0x53/0x100
[ 41.524157] netlink_unicast+0x23b/0x390
[ 41.524484] netlink_sendmsg+0x1f2/0x440
[ 41.524826] __sys_sendto+0x1d8/0x1f0
[ 41.525145] __x64_sys_sendto+0x1f/0x30
[ 41.525467] do_syscall_64+0xa5/0x1b0
[ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a
[ 41.526213] RIP: 0033:0x7fbc4cfcea9a
[ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[ 41.527942] RSP: 002b:00007f
---truncated---
CVE-2024-35969
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
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
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
copy_from_sockptr include/linux/sockptr.h:55 [inline]
xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fb40587de69
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
</TASK>
Allocated by task 7549:
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:370 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
kasan_kmalloc include/linux/kasan.h:211 [inline]
__do_kmalloc_node mm/slub.c:3966 [inline]
__kmalloc+0x233/0x4a0 mm/slub.c:3979
kmalloc include/linux/slab.h:632 [inline]
__cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
The buggy address belongs to the object at ffff888028c6cde0
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 1 bytes to the right of
allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
The buggy address belongs to the physical page:
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
prep_new_page mm/page_alloc.c:
---truncated---
CVE-2024-35976
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync
request state before assigning reference to a new one.
CVE-2024-35978
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
raid1: fix use-after-free for original bio in raid1_write_request()
r1_bio->bios[] is used to record new bios that will be issued to
underlying disks, however, in raid1_write_request(), r1_bio->bios[]
will set to the original bio temporarily. Meanwhile, if blocked rdev
is set, free_r1bio() will be called causing that all r1_bio->bios[]
to be freed:
raid1_write_request()
r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL
for (i = 0; i < disks; i++) -> for each rdev in conf
// first rdev is normal
r1_bio->bios[0] = bio; -> set to original bio
// second rdev is blocked
if (test_bit(Blocked, &rdev->flags))
break
if (blocked_rdev)
free_r1bio()
put_all_bios()
bio_put(r1_bio->bios[0]) -> original bio is freed
Test scripts:
mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean
fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \
-iodepth=128 -name=test -direct=1
echo blocked > /sys/block/md0/md/rd2/state
Test result:
BUG bio-264 (Not tainted): Object already free
-----------------------------------------------------------------------------
Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869
kmem_cache_alloc+0x324/0x480
mempool_alloc_slab+0x24/0x50
mempool_alloc+0x6e/0x220
bio_alloc_bioset+0x1af/0x4d0
blkdev_direct_IO+0x164/0x8a0
blkdev_write_iter+0x309/0x440
aio_write+0x139/0x2f0
io_submit_one+0x5ca/0xb70
__do_sys_io_submit+0x86/0x270
__x64_sys_io_submit+0x22/0x30
do_syscall_64+0xb1/0x210
entry_SYSCALL_64_after_hwframe+0x6c/0x74
Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869
kmem_cache_free+0x28c/0x550
mempool_free_slab+0x1f/0x30
mempool_free+0x40/0x100
bio_free+0x59/0x80
bio_put+0xf0/0x220
free_r1bio+0x74/0xb0
raid1_make_request+0xadf/0x1150
md_handle_request+0xc7/0x3b0
md_submit_bio+0x76/0x130
__submit_bio+0xd8/0x1d0
submit_bio_noacct_nocheck+0x1eb/0x5c0
submit_bio_noacct+0x169/0xd40
submit_bio+0xee/0x1d0
blkdev_direct_IO+0x322/0x8a0
blkdev_write_iter+0x309/0x440
aio_write+0x139/0x2f0
Since that bios for underlying disks are not allocated yet, fix this
problem by using mempool_free() directly to free the r1_bio.
CVE-2024-35979
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid infinite loop trying to resize local TT
If the MTU of one of an attached interface becomes too small to transmit
the local translation table then it must be resized to fit inside all
fragments (when enabled) or a single packet.
But if the MTU becomes too low to transmit even the header + the VLAN
specific part then the resizing of the local TT will never succeed. This
can for example happen when the usable space is 110 bytes and 11 VLANs are
on top of batman-adv. In this case, at least 116 byte would be needed.
There will just be an endless spam of
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
in the log but the function will never finish. Problem here is that the
timeout will be halved all the time and will then stagnate at 0 and
therefore never be able to reduce the table even more.
There are other scenarios possible with a similar result. The number of
BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
high to fit inside a packet. Such a scenario can therefore happen also with
only a single VLAN + 7 non-purgable addresses - requiring at least 120
bytes.
While this should be handled proactively when:
* interface with too low MTU is added
* VLAN is added
* non-purgeable local mac is added
* MTU of an attached interface is reduced
* fragmentation setting gets disabled (which most likely requires dropping
attached interfaces)
not all of these scenarios can be prevented because batman-adv is only
consuming events without the the possibility to prevent these actions
(non-purgable MAC address added, MTU of an attached interface is reduced).
It is therefore necessary to also make sure that the code is able to handle
also the situations when there were already incompatible system
configuration are present.
CVE-2024-35982
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Use access_width over bit_width for system memory accesses
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
cannot be depended on to be always on a clean 8b boundary. This was
uncovered on the Cobalt 100 platform.
SError Interrupt on CPU26, code 0xbe000011 -- SError
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
pc : cppc_get_perf_caps+0xec/0x410
lr : cppc_get_perf_caps+0xe8/0x410
sp : ffff8000155ab730
x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
5.15.2.1-13 #1
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
Call trace:
dump_backtrace+0x0/0x1e0
show_stack+0x24/0x30
dump_stack_lvl+0x8c/0xb8
dump_stack+0x18/0x34
panic+0x16c/0x384
add_taint+0x0/0xc0
arm64_serror_panic+0x7c/0x90
arm64_is_fatal_ras_serror+0x34/0xa4
do_serror+0x50/0x6c
el1h_64_error_handler+0x40/0x74
el1h_64_error+0x7c/0x80
cppc_get_perf_caps+0xec/0x410
cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
cpufreq_online+0x2dc/0xa30
cpufreq_add_dev+0xc0/0xd4
subsys_interface_register+0x134/0x14c
cpufreq_register_driver+0x1b0/0x354
cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
do_one_initcall+0x50/0x250
do_init_module+0x60/0x27c
load_module+0x2300/0x2570
__do_sys_finit_module+0xa8/0x114
__arm64_sys_finit_module+0x2c/0x3c
invoke_syscall+0x78/0x100
el0_svc_common.constprop.0+0x180/0x1a0
do_el0_svc+0x84/0xa0
el0_svc+0x2c/0xc0
el0t_64_sync_handler+0xa4/0x12c
el0t_64_sync+0x1a4/0x1a8
Instead, use access_width to determine the size and use the offset and
width to shift and mask the bits to read/write out. Make sure to add a
check for system memory since pcc redefines the access_width to
subspace id.
If access_width is not set, then fall back to using bit_width.
[ rjw: Subject and changelog edits, comment adjustments ]
CVE-2024-35995
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
However, this is not necessary, because I2C core already has its own
locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in
i2c_hid_xfer() and an interrupt happens, the interrupt handler
(i2c_hid_irq) will check this flag and return immediately without doing
anything, then the interrupt handler will be invoked again in an
infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the
flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.
CVE-2024-35997
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix lock ordering potential deadlock in cifs_sync_mid_result
Coverity spotted that the cifs_sync_mid_result function could deadlock
"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires
lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"
Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
CVE-2024-35998
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
Issue reported by customer during SRIOV testing, call trace:
When both i40e and the i40iw driver are loaded, a warning
in check_flush_dependency is being triggered. This seems
to be because of the i40e driver workqueue is allocated with
the WQ_MEM_RECLAIM flag, and the i40iw one is not.
Similar error was encountered on ice too and it was fixed by
removing the flag. Do the same for i40e too.
[Feb 9 09:08] ------------[ cut here ]------------
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
flushing !WQ_MEM_RECLAIM infiniband:0x0
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
check_flush_dependency+0x10b/0x120
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
dm_region_hash dm_log dm_mod fuse
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
SE5C620.86B.02.01.0013.121520200651 12/15/2020
[ +0.000001] Workqueue: i40e i40e_service_task [i40e]
[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
0000000000000027
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
ffff94d47f620bc0
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
00000000ffff7fff
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
ffff94c5451ea180
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
ffff94c5f1330ab0
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)
knlGS:0000000000000000
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
00000000007706f0
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ +0.000001] PKRU: 55555554
[ +0.000001] Call Trace:
[ +0.000001] <TASK>
[ +0.000002] ? __warn+0x80/0x130
[ +0.000003] ? check_flush_dependency+0x10b/0x120
[ +0.000002] ? report_bug+0x195/0x1a0
[ +0.000005] ? handle_bug+0x3c/0x70
[ +0.000003] ? exc_invalid_op+0x14/0x70
[ +0.000002] ? asm_exc_invalid_op+0x16/0x20
[ +0.000006] ? check_flush_dependency+0x10b/0x120
[ +0.000002] ? check_flush_dependency+0x10b/0x120
[ +0.000002] __flush_workqueue+0x126/0x3f0
[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]
[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]
[ +0.000020] i40iw_close+0x4b/0x90 [irdma]
[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
[ +0.000035] i40e_service_task+0x126/0x190 [i40e]
[ +0.000024] process_one_work+0x174/0x340
[ +0.000003] worker_th
---truncated---
CVE-2024-36004
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
Extend a critical section to prevent chan from early freeing.
Also make the l2cap_connect() return type void. Nothing is using the
returned value but it is ugly to return a potentially freed pointer.
Making it void will help with backports because earlier kernels did use
the return value. Now the compile will break for kernels where this
patch is not a complete fix.
Call stack summary:
[use]
l2cap_bredr_sig_cmd
l2cap_connect
mutex_lock(&conn->chan_lock);
| chan = pchan->ops->new_connection(pchan); <- alloc chan
| __l2cap_chan_add(conn, chan);
| l2cap_chan_hold(chan);
| list_add(&chan->list, &conn->chan_l); ... (1)
mutex_unlock(&conn->chan_lock);
chan->conf_state ... (4) <- use after free
[free]
l2cap_conn_del
mutex_lock(&conn->chan_lock);
| foreach chan in conn->chan_l: ... (2)
| l2cap_chan_put(chan);
| l2cap_chan_destroy
| kfree(chan) ... (3) <- chan freed
mutex_unlock(&conn->chan_lock);
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read
include/linux/instrumented.h:68 [inline]
BUG: KASAN: slab-use-after-free in _test_bit
include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0
net/bluetooth/l2cap_core.c:4260
Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
CVE-2024-36013
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/arm/malidp: fix a possible null pointer dereference
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
no check is performed. In order to prevent null pointer dereferencing,
ensure that mw_state is checked before calling
__drm_atomic_helper_connector_reset.
CVE-2024-36014
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ppdev: Add an error check in register_device
In register_device, the return value of ida_simple_get is unchecked,
in witch ida_simple_get will use an invalid index value.
To address this issue, index should be checked after ida_simple_get. When
the index value is abnormal, a warning message should be printed, the port
should be dropped, and the value should be recorded.
CVE-2024-36015
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following:
- side A configures the n_gsm in basic option mode
- side B sends the header of a basic option mode frame with data length 1
- side A switches to advanced option mode
- side B sends 2 data bytes which exceeds gsm->len
Reason: gsm->len is not used in advanced option mode.
- side A switches to basic option mode
- side B keeps sending until gsm0_receive() writes past gsm->buf
Reason: Neither gsm->state nor gsm->len have been reset after
reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less
than. Also add upper limit checks against the constant MAX_MRU in
gsm0_receive() and gsm1_receive() to harden against memory corruption of
gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the
user configuration and actual payload size.
CVE-2024-36016
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
struct ifla_vf_vlan_info so the size of such attribute needs to be at least
of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
which is less than sizeof(struct ifla_vf_vlan_info) so this validation
is not enough and a too small attribute might be cast to a
struct ifla_vf_vlan_info, this might result in an out of bands
read access when accessing the saved (casted) entry in ivvl.
CVE-2024-36017
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()
The app_reply->elem[] array is allocated earlier in this function and it
has app_req.num_ports elements. Thus this > comparison needs to be >= to
prevent memory corruption.
CVE-2024-36025
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-msm: pervent access to suspended controller
Generic sdhci code registers LED device and uses host->runtime_suspended
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
which causes a crash when LED is accessed while controller is runtime
suspended. Fix this by setting the flag correctly.
CVE-2024-36029
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: tproxy: bail out if IP has been disabled on the device
syzbot reports:
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
[..]
RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62
Call Trace:
nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]
nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168
__in_dev_get_rcu() can return NULL, so check for this.
CVE-2024-36270
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
syzbot reported that nf_reinject() could be called without rcu_read_lock() :
WARNING: suspicious RCU usage
6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor.4/13427:
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]
#0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]
#1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
stack backtrace:
CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]
nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397
nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]
instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172
rcu_do_batch kernel/rcu/tree.c:2196 [inline]
rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471
handle_softirqs+0x2d6/0x990 kernel/softirq.c:554
__do_softirq kernel/softirq.c:588 [inline]
invoke_softirq kernel/softirq.c:428 [inline]
__irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
</IRQ>
<TASK>
CVE-2024-36286
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix loop termination condition in gss_free_in_token_pages()
The in_token->pages[] array is not NULL terminated. This results in
the following KASAN splat:
KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]
CVE-2024-36288
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fpga: bridge: add owner module and take its refcount
The current implementation of the fpga bridge assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the bridge if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_bridge
struct and use it to take the module's refcount. Modify the function for
registering a bridge to take an additional owner module parameter and
rename it to avoid conflicts. Use the old function name for a helper macro
that automatically sets the module that registers the bridge as the owner.
This ensures compatibility with existing low-level control modules and
reduces the chances of registering a bridge without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga bridge.
Other changes: opportunistically move put_device() from __fpga_bridge_get()
to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since
the bridge device is taken in these functions.
CVE-2024-36479
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A vulnerability was identified in the kjd/idna library, specifically within the `idna.encode()` function, affecting version 3.6. The issue arises from the function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This vulnerability is triggered by a crafted input that causes the `idna.encode()` function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size.
CVE-2024-3651
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-idna-2.5-3.13.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-idna-2.5-3.13.1
moderate
unknown
CVE-2024-36592
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: add missing firmware sanity checks
Add the missing sanity checks when parsing the firmware files before
downloading them to avoid accessing and corrupting memory beyond the
vmalloced buffer.
CVE-2024-36880
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in ops_init
net_alloc_generic is called by net_alloc, which is called without any
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
is read twice, first to allocate an array, then to set s.len, which is
later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is
registering a new pernet ops, increments max_gen_ptrs, which is then used
to set s.len with a larger than allocated length for the variable array.
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.
CVE-2024-36883
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
linux/net/core/skbuff.c:1183
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.0-debian-1.16.0-5 04/01/2014
Call Trace:
<IRQ>
__dump_stack linux/lib/dump_stack.c:88
dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
print_address_description linux/mm/kasan/report.c:377
print_report+0xc4/0x620 linux/mm/kasan/report.c:488
kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
skb_release_all linux/net/core/skbuff.c:1094
__kfree_skb linux/net/core/skbuff.c:1108
kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
kfree_skb linux/./include/linux/skbuff.h:1244
tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
__udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
NF_HOOK linux/./include/linux/netfilter.h:314
NF_HOOK linux/./include/linux/netfilter.h:308
ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
dst_input linux/./include/net/dst.h:461
ip_rcv_finish linux/net/ipv4/ip_input.c:449
NF_HOOK linux/./include/linux/netfilter.h:314
NF_HOOK linux/./include/linux/netfilter.h:308
ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
__netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
__netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
__napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
napi_poll linux/net/core/dev.c:6645
net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
__do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
do_softirq linux/kernel/softirq.c:454
do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
</IRQ>
<TASK>
__local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
local_bh_enable linux/./include/linux/bottom_half.h:33
rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
__dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
dev_queue_xmit linux/./include/linux/netdevice.h:3169
neigh_hh_output linux/./include/net/neighbour.h:526
neigh_output linux/./include/net/neighbour.h:540
ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
__ip_finish_output linux/net/ipv4/ip_output.c:313
__ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
NF_HOOK_COND linux/./include/linux/netfilter.h:303
ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
dst_output linux/./include/net/dst.h:451
ip_local_out linux/net/ipv4/ip_output.c:129
ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
sock_sendmsg_nosec linux/net/socket.c:730
__sock_sendmsg linux/net/socket.c:745
__sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
__do_sys_sendto linux/net/socket.c:2203
__se_sys_sendto linux/net/socket.c:2199
__x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
do_syscall_x64 linux/arch/x86/entry/common.c:52
do_syscall_
---truncated---
CVE-2024-36886
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC. There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect. For a DWC3 based implementation, the callstack looks
like the following:
DWC3 Gadget FFS Application
dwc3_gadget_soft_disconnect() ...
--> dwc3_stop_active_transfers()
--> dwc3_gadget_giveback(-ESHUTDOWN)
--> ffs_epfile_async_io_complete() ffs_aio_cancel()
--> usb_ep_free_request() --> usb_ep_dequeue()
There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data->req) the FFS
application is also referencing it for the usb_ep_dequeue() call. This can
lead to accessing a stale/hanging pointer.
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
However, in order to properly implement locking to mitigate this issue, the
spinlock can't be added to ffs_epfile_async_io_complete(), as
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
function driver's completion handler in the same context. Hence, leading
into a deadlock.
Fix this issue by moving the usb_ep_free_request() back to
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req
to NULL after freeing it within the ffs->eps_lock. This resolves the race
condition above, as the ffs_aio_cancel() routine will not continue
attempting to dequeue a request that has already been freed, or the
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
done referencing it.
This fix depends on
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status
consistently")
CVE-2024-36894
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev()
returns NULL in ip6_output(). Most places in IPv6 stack
deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237
Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff
RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000
RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48
RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad
R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0
R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000
FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
NF_HOOK include/linux/netfilter.h:314 [inline]
ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358
sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248
sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653
sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783
sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]
sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212
sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169
sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73
__sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234
sctp_connect net/sctp/socket.c:4819 [inline]
sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
__sys_connect_file net/socket.c:2048 [inline]
__sys_connect+0x2df/0x310 net/socket.c:2065
__do_sys_connect net/socket.c:2075 [inline]
__se_sys_connect net/socket.c:2072 [inline]
__x64_sys_connect+0x7a/0x90 net/socket.c:2072
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-36901
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
syzbot is able to trigger the following crash [1],
caused by unsafe ip6_dst_idev() use.
Indeed ip6_dst_idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
ip6_route_output include/net/ip6_route.h:93 [inline]
ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
__sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
sctp_connect net/sctp/socket.c:4819 [inline]
sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
__sys_connect_file net/socket.c:2048 [inline]
__sys_connect+0x2df/0x310 net/socket.c:2065
__do_sys_connect net/socket.c:2075 [inline]
__se_sys_connect net/socket.c:2072 [inline]
__x64_sys_connect+0x7a/0x90 net/socket.c:2072
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-36902
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by
cross-syn connections, mostly used by fuzzers.
In the following crash [1], syzbot managed to trigger a divide
by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions,
without ever calling tcp_init_transfer(),
meaning tcp_init_buffer_space() is also not called.
TCP_CLOSE
connect()
TCP_SYN_SENT
TCP_SYN_RECV
shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)
TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not
perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,
which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,
and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH
context, and must use GFP_ATOMIC allocations.
[1]
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
Call Trace:
<TASK>
tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
sock_recvmsg_nosec net/socket.c:1046 [inline]
sock_recvmsg+0x109/0x280 net/socket.c:1068
____sys_recvmsg+0x1db/0x470 net/socket.c:2803
___sys_recvmsg net/socket.c:2845 [inline]
do_recvmmsg+0x474/0xae0 net/socket.c:2939
__sys_recvmmsg net/socket.c:3018 [inline]
__do_sys_recvmmsg net/socket.c:3041 [inline]
__se_sys_recvmmsg net/socket.c:3034 [inline]
__x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7faeb6363db9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
CVE-2024-36905
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies
syzbot reported unsafe calls to copy_from_sockptr() [1]
Use copy_safe_from_sockptr() instead.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078
CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
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
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
copy_from_sockptr include/linux/sockptr.h:55 [inline]
nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
__do_sys_setsockopt net/socket.c:2343 [inline]
__se_sys_setsockopt net/socket.c:2340 [inline]
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
do_syscall_64+0xfd/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7f7fac07fd89
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 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:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89
RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
CVE-2024-36915
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
block: fix overflow in blk_ioctl_discard()
There is no check for overflow of 'start + len' in blk_ioctl_discard().
Hung task occurs if submit an discard ioctl with the following param:
start = 0x80000000000ff000, len = 0x8000000000fff000;
Add the overflow validation now.
CVE-2024-36917
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
The session resources are used by FW and driver when session is offloaded,
once session is uploaded these resources are not used. The lock is not
required as these fields won't be used any longer. The offload and upload
calls are sequential, hence lock is not required.
This will suppress following BUG_ON():
[ 449.843143] ------------[ cut here ]------------
[ 449.848302] kernel BUG at mm/vmalloc.c:2727!
[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
Rebooting.
[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
[ 449.882910] RIP: 0010:vunmap+0x2e/0x30
[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41
[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 449.993028] Call Trace:
[ 449.995756] __iommu_dma_free+0x96/0x100
[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]
[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]
[ 450.023103] process_one_work+0x1e8/0x3c0
[ 450.027581] worker_thread+0x50/0x3b0
[ 450.031669] ? rescuer_thread+0x370/0x370
[ 450.036143] kthread+0x149/0x170
[ 450.039744] ? set_kthread_struct+0x40/0x40
[ 450.044411] ret_from_fork+0x22/0x30
[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls
[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---
CVE-2024-36919
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-36923
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the
hbalock to avoid potential deadlock.
CVE-2024-36924
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bna: ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul
instead of memdup_user.
CVE-2024-36934
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which
syzbot reported [1].
[1]
BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:
sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]
sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843
sk_psock_put include/linux/skmsg.h:459 [inline]
sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648
unix_release+0x4b/0x80 net/unix/af_unix.c:1048
__sock_release net/socket.c:659 [inline]
sock_close+0x68/0x150 net/socket.c:1421
__fput+0x2c1/0x660 fs/file_table.c:422
__fput_sync+0x44/0x60 fs/file_table.c:507
__do_sys_close fs/open.c:1556 [inline]
__se_sys_close+0x101/0x1b0 fs/open.c:1541
__x64_sys_close+0x1f/0x30 fs/open.c:1541
do_syscall_64+0xd3/0x1d0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:
sk_psock_data_ready include/linux/skmsg.h:464 [inline]
sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555
sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606
sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]
sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202
unix_read_skb net/unix/af_unix.c:2546 [inline]
unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682
sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223
unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x140/0x180 net/socket.c:745
____sys_sendmsg+0x312/0x410 net/socket.c:2584
___sys_sendmsg net/socket.c:2638 [inline]
__sys_sendmsg+0x1e9/0x280 net/socket.c:2667
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x46/0x50 net/socket.c:2674
do_syscall_64+0xd3/0x1d0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer
dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer
similarly due to no protection of saved_data_ready. Here is another
different caller causing the same issue because of the same reason. So
we should protect it with sk_callback_lock read lock because the writer
side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
To avoid errors that could happen in future, I move those two pairs of
lock into the sk_psock_data_ready(), which is suggested by John Fastabend.
CVE-2024-36938
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfs: Handle error of rpc_proc_register() in nfs_net_init().
syzkaller reported a warning [0] triggered while destroying immature
netns.
rpc_proc_register() was called in init_nfs_fs(), but its error
has been ignored since at least the initial commit 1da177e4c3f4
("Linux-2.6.12-rc2").
Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs
in net namespaces") converted the procfs to per-netns and made
the problem more visible.
Even when rpc_proc_register() fails, nfs_net_init() could succeed,
and thus nfs_net_exit() will be called while destroying the netns.
Then, remove_proc_entry() will be called for non-existing proc
directory and trigger the warning below.
Let's handle the error of rpc_proc_register() properly in nfs_net_init().
[0]:
name 'nfs'
WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Modules linked in:
CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb
RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c
RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc
R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8
FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310
nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438
ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170
setup_net+0x46c/0x660 net/core/net_namespace.c:372
copy_net_ns+0x244/0x590 net/core/net_namespace.c:505
create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228
ksys_unshare+0x342/0x760 kernel/fork.c:3322
__do_sys_unshare kernel/fork.c:3393 [inline]
__se_sys_unshare kernel/fork.c:3391 [inline]
__x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0x7f30d0febe5d
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:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600
RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
</TASK>
CVE-2024-36939
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well.
CVE-2024-36940
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: don't free NULL coalescing rule
If the parsing fails, we can dereference a NULL pointer here.
CVE-2024-36941
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: sync all devices to wait all processes being evicted
If there are more than one device doing reset in parallel, the first
device will call kfd_suspend_all_processes() to evict all processes
on all devices, this call takes time to finish. other device will
start reset and recover without waiting. if the process has not been
evicted before doing recover, it will be restored, then caused page
fault.
CVE-2024-36949
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firewire: ohci: mask bus reset interrupts between ISR and bottom half
In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.
Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.
irq_handler logs the bus reset interrupt. However, we can't clear the bus
reset event flag in irq_handler, because we won't service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.
This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.
irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won't be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.
CVE-2024-36950
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()
If we fail to allocate propname buffer, we need to drop the reference
count we just took. Because the pinctrl_dt_free_maps() includes the
droping operation, here we call it directly.
CVE-2024-36959
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
CVE-2024-36960
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it
to be able to set (among others) the suid bit. This was presumably not
the intent since the unix extended bits are handled explicitly and
conditionally on .u.
CVE-2024-36964
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
overflow since hdev->le_mtu may not fall in the valid range.
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
process earlier if MTU is invalid.
Also, add a missing validation in read_buffer_size() and make it return
an error value if the validation fails.
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
kzalloc failure and invalid MTU value.
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci0 hci_rx_work
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
<TASK>
l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
process_one_work kernel/workqueue.c:3254 [inline]
process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
worker_thread+0x926/0xe70 kernel/workqueue.c:3416
kthread+0x2e3/0x380 kernel/kthread.c:388
ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
CVE-2024-36968
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fpga: manager: add owner module and take its refcount
The current implementation of the fpga manager assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the manager if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_manager
struct and use it to take the module's refcount. Modify the functions for
registering the manager to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the manager as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a manager without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga manager.
Other changes: opportunistically move put_device() from __fpga_mgr_get() to
fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the
manager device is taken in these functions.
CVE-2024-37021
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix crash on racing fsync and size-extending write into prealloc
We have been seeing crashes on duplicate keys in
btrfs_set_item_key_safe():
BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
------------[ cut here ]------------
kernel BUG at fs/btrfs/ctree.c:2620!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]
With the following stack trace:
#0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
#1 btrfs_drop_extents (fs/btrfs/file.c:411:4)
#2 log_one_extent (fs/btrfs/tree-log.c:4732:9)
#3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
#4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
#5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
#6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
#7 btrfs_sync_file (fs/btrfs/file.c:1933:8)
#8 vfs_fsync_range (fs/sync.c:188:9)
#9 vfs_fsync (fs/sync.c:202:9)
#10 do_fsync (fs/sync.c:212:9)
#11 __do_sys_fdatasync (fs/sync.c:225:9)
#12 __se_sys_fdatasync (fs/sync.c:223:1)
#13 __x64_sys_fdatasync (fs/sync.c:223:1)
#14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
#15 do_syscall_64 (arch/x86/entry/common.c:83:7)
#16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)
So we're logging a changed extent from fsync, which is splitting an
extent in the log tree. But this split part already exists in the tree,
triggering the BUG().
This is the state of the log tree at the time of the crash, dumped with
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
to get more details than btrfs_print_leaf() gives us:
>>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])
leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
leaf 33439744 flags 0x100000000000000
fs uuid e5bd3946-400c-4223-8923-190ef1f18677
chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
generation 7 transid 9 size 8192 nbytes 8473563889606862198
block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
sequence 204 flags 0x10(PREALLOC)
atime 1716417703.220000000 (2024-05-22 15:41:43)
ctime 1716417704.983333333 (2024-05-22 15:41:44)
mtime 1716417704.983333333 (2024-05-22 15:41:44)
otime 17592186044416.000000000 (559444-03-08 01:40:16)
item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
index 195 namelen 3 name: 193
item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
location key (0 UNKNOWN.0 0) type XATTR
transid 7 data_len 1 name_len 6
name: user.a
data a
item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 303144960 nr 12288
extent data offset 0 nr 4096 ram 12288
extent compression 0 (none)
item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
generation 9 type 2 (prealloc)
prealloc data disk byte 303144960 nr 12288
prealloc data offset 4096 nr 8192
item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
generation 9 type 2 (prealloc)
prealloc data disk byte 303144960 nr 12288
prealloc data offset 8192 nr 4096
...
So the real problem happened earlier: notice that items 4 (4k-12k) and 5
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
item 5 starts at i_size.
Here is the state of
---truncated---
CVE-2024-37354
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can modify the plaintext Extra Count field of a confidential GSS krb5 wrap token, causing the unwrapped token to appear truncated to the application.
CVE-2024-37370
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
important
In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.
CVE-2024-37371
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
moderate
urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3's `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.
CVE-2024-37891
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-urllib3-1.25.10-3.43.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-urllib3-1.25.10-3.43.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_rx_work
syzbot reported the following uninit-value access issue [1]
nci_rx_work() parses received packet from ndev->rx_q. It should be
validated header size, payload size and total packet size before
processing the packet. If an invalid packet is detected, it should be
silently discarded.
CVE-2024-38381
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.
CVE-2024-38428
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:wget-1.14-21.25.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: xmit: make sure we have at least eth header len bytes
syzbot triggered an uninit value[1] error in bridge device's xmit path
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
we can actually pull that amount instead of assuming.
Tested with dropwatch:
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
origin: software
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
protocol: 0x88a8
length: 2
original length: 2
drop reason: PKT_TOO_SMALL
[1]
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
__bpf_tx_skb net/core/filter.c:2136 [inline]
__bpf_redirect_common net/core/filter.c:2180 [inline]
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
____bpf_clone_redirect net/core/filter.c:2460 [inline]
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
__bpf_prog_run include/linux/filter.h:657 [inline]
bpf_prog_run include/linux/filter.h:664 [inline]
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-38538
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the
resp_pkts queue and then a decision is made whether to run the completer
task inline or schedule it. Finally the skb is dereferenced to bump a 'hw'
performance counter. This is wrong because if the completer task is
already running in a separate thread it may have already processed the skb
and freed it which can cause a seg fault. This has been observed
infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until
after the counter is accessed.
CVE-2024-38544
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.
Use the xa_lock() to protect the CQ refcount.
CVE-2024-38545
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm: vc4: Fix possible null pointer dereference
In vc4_hdmi_audio_init() of_get_address() may return
NULL which is later dereferenced. Fix this bug by adding NULL check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-38546
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
of 0 bytes. Currently, no such check exists and the kernel will panic if
a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
verifying that we now return EINVAL.
CVE-2024-38549
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential index out of bounds in color transformation function
Fixes index out of bounds issue in the color transformation function.
The issue could occur when the index 'i' exceeds the number of transfer
function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds, an error message is
logged and the function returns false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
CVE-2024-38552
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fec: remove .ndo_poll_controller to avoid deadlocks
There is a deadlock issue found in sungem driver, please refer to the
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
deadlocks"). The root cause of the issue is that netpoll is in atomic
context and disable_irq() is called by .ndo_poll_controller interface
of sungem driver, however, disable_irq() might sleep. After analyzing
the implementation of fec_poll_controller(), the fec driver should have
the same issue. Due to the fec driver uses NAPI for TX completions, the
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
so fec_poll_controller() can be safely removed.
CVE-2024-38553
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
- OVS_PACKET_ATTR_PACKET - Binary packet content.
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
with the metadata like conntrack state, input port, recirculation id,
etc. Then the packet itself gets parsed to populate the rest of the
keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it
first zeroes out fields in the key corresponding to Neighbor Discovery
information even if it is not an ND packet.
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares
the space between 'nd' and 'ct_orig' that holds the original tuple
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
ND packets should not normally have conntrack state, so it's fine to
share the space, but normal ICMPv6 Echo packets or maybe other types of
ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination
address being wiped from the original conntrack tuple leading to
incorrect packet matching and potentially executing wrong actions
in case this packet recirculates within the datapath or goes back
to userspace.
ND fields should not be accessed in non-ND packets, so not clearing
them should be fine. Executing memset() only for actual ND packets to
avoid the issue.
Initializing the whole thing before parsing is needed because ND packet
may not contain all the options.
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
affect packets entering OVS datapath from network interfaces, because
in this case CT metadata is populated from skb after the packet is
already parsed.
CVE-2024-38558
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Ensure the copied buf is NUL terminated
Currently, we allocate a count-sized kernel buffer and copy count from
userspace to that buffer. Later, we use kstrtouint on this buffer but we
don't ensure that the string is terminated inside the buffer, this can
lead to OOB read when using kstrtouint. Fix this issue by using
memdup_user_nul instead of memdup_user.
CVE-2024-38559
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: bfa: Ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
of memdup_user.
CVE-2024-38560
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use
not having an expected type to it.
Fix the issue by checking for the existence of all proper
endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report:
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
<TASK>
ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275
ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]
ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]
ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655
usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:560 [inline]
really_probe+0x249/0xb90 drivers/base/dd.c:639
__driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
__device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
__device_attach+0x1e4/0x530 drivers/base/dd.c:1008
bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
device_add+0xbd9/0x1e90 drivers/base/core.c:3517
usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293
call_driver_probe drivers/base/dd.c:560 [inline]
really_probe+0x249/0xb90 drivers/base/dd.c:639
__driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
__device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
__device_attach+0x1e4/0x530 drivers/base/dd.c:1008
bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
device_add+0xbd9/0x1e90 drivers/base/core.c:3517
usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573
hub_port_connect drivers/usb/core/hub.c:5353 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]
port_event drivers/usb/core/hub.c:5653 [inline]
hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
kthread+0x2e8/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
CVE-2024-38565
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: add a proper sanity check for endpoints
Syzkaller reports [1] hitting a warning which is caused by presence
of a wrong endpoint type at the URB sumbitting stage. While there
was a check for a specific 4th endpoint, since it can switch types
between bulk and interrupt, other endpoints are trusted implicitly.
Similar warning is triggered in a couple of other syzbot issues [2].
Fix the issue by doing a comprehensive check of all endpoints
taking into account difference between high- and full-speed
configuration.
[1] Syzkaller report:
...
WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
<TASK>
carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504
carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]
carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]
carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028
request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
kthread+0x2e8/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>
[2] Related syzkaller crashes:
CVE-2024-38567
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: Fix buffer size for tag 66 packet
The 'TAG 66 Packet Format' description is missing the cipher code and
checksum fields that are packed into the message packet. As a result,
the buffer allocated for the packet is 3 bytes too small and
write_tag_66_packet() will write up to 3 bytes past the end of the
buffer.
Fix this by increasing the size of the allocation so the whole packet
will always fit in the buffer.
This fixes the below kasan slab-out-of-bounds bug:
BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
Write of size 1 at addr ffff88800afbb2a5 by task touch/181
CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x4c/0x70
print_report+0xc5/0x610
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
? kasan_complete_mode_report_info+0x44/0x210
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
kasan_report+0xc2/0x110
? ecryptfs_generate_key_packet_set+0x7d6/0xde0
__asan_store1+0x62/0x80
ecryptfs_generate_key_packet_set+0x7d6/0xde0
? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
? __alloc_pages+0x2e2/0x540
? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
? dentry_open+0x8f/0xd0
ecryptfs_write_metadata+0x30a/0x550
? __pfx_ecryptfs_write_metadata+0x10/0x10
? ecryptfs_get_lower_file+0x6b/0x190
ecryptfs_initialize_file+0x77/0x150
ecryptfs_create+0x1c2/0x2f0
path_openat+0x17cf/0x1ba0
? __pfx_path_openat+0x10/0x10
do_filp_open+0x15e/0x290
? __pfx_do_filp_open+0x10/0x10
? __kasan_check_write+0x18/0x30
? _raw_spin_lock+0x86/0xf0
? __pfx__raw_spin_lock+0x10/0x10
? __kasan_check_write+0x18/0x30
? alloc_fd+0xf4/0x330
do_sys_openat2+0x122/0x160
? __pfx_do_sys_openat2+0x10/0x10
__x64_sys_openat+0xef/0x170
? __pfx___x64_sys_openat+0x10/0x10
do_syscall_64+0x60/0xd0
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
RIP: 0033:0x7f00a703fd67
Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
</TASK>
Allocated by task 181:
kasan_save_stack+0x2f/0x60
kasan_set_track+0x29/0x40
kasan_save_alloc_info+0x25/0x40
__kasan_kmalloc+0xc5/0xd0
__kmalloc+0x66/0x160
ecryptfs_generate_key_packet_set+0x6d2/0xde0
ecryptfs_write_metadata+0x30a/0x550
ecryptfs_initialize_file+0x77/0x150
ecryptfs_create+0x1c2/0x2f0
path_openat+0x17cf/0x1ba0
do_filp_open+0x15e/0x290
do_sys_openat2+0x122/0x160
__x64_sys_openat+0xef/0x170
do_syscall_64+0x60/0xd0
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
CVE-2024-38578
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: bcm - Fix pointer arithmetic
In spu2_dump_omd() value of ptr is increased by ciph_key_len
instead of hash_iv_len which could lead to going beyond the
buffer boundaries.
Fix this bug by changing ciph_key_len to hash_iv_len.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-38579
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
epoll: be better about file lifetimes
epoll can call out to vfs_poll() with a file pointer that may race with
the last 'fput()'. That would make f_count go down to zero, and while
the ep->mtx locking means that the resulting file pointer tear-down will
be blocked until the poll returns, it means that f_count is already
dead, and any use of it won't actually get a reference to the file any
more: it's dead regardless.
Make sure we have a valid ref on the file pointer before we call down to
vfs_poll() from the epoll routines.
CVE-2024-38580
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr ffff888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
[...]
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
print_report+0xcf/0x610
kasan_report+0xb5/0xe0
ftrace_location+0x90/0x120
register_kprobe+0x14b/0xa40
kprobe_init+0x2d/0xff0 [kprobe_example]
do_one_initcall+0x8f/0x2d0
do_init_module+0x13a/0x3c0
load_module+0x3082/0x33d0
init_module_from_file+0xd2/0x130
__x64_sys_finit_module+0x306/0x440
do_syscall_64+0x68/0x140
entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:
CPU1 | CPU2
register_kprobes() { | delete_module() {
check_kprobe_address_safe() { |
arch_check_ftrace_location() { |
ftrace_location() { |
lookup_rec() // USE! | ftrace_release_mod() // Free!
To fix this issue:
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
2. Use ftrace_location_range() instead of lookup_rec() in
ftrace_location();
3. Call synchronize_rcu() before freeing any ftrace pages both in
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().
CVE-2024-38588
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netrom: fix possible dead-lock in nr_rt_ioctl()
syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
[1]
WARNING: possible circular locking dependency detected
6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
------------------------------------------------------
syz-executor350/5129 is trying to acquire lock:
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
but task is already holding lock:
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (nr_node_list_lock){+...}-{2:2}:
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_remove_node net/netrom/nr_route.c:299 [inline]
nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
sock_do_ioctl+0x158/0x460 net/socket.c:1222
sock_ioctl+0x629/0x8e0 net/socket.c:1341
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&nr_node->node_lock){+...}-{2:2}:
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
__lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_node_lock include/net/netrom.h:152 [inline]
nr_dec_obs net/netrom/nr_route.c:464 [inline]
nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
sock_do_ioctl+0x158/0x460 net/socket.c:1222
sock_ioctl+0x629/0x8e0 net/socket.c:1341
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(nr_node_list_lock);
lock(&nr_node->node_lock);
lock(nr_node_list_lock);
lock(&nr_node->node_lock);
*** DEADLOCK ***
1 lock held by syz-executor350/5129:
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
#0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
#0: ffffffff8f70
---truncated---
CVE-2024-38589
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
A data-race condition has been identified in af_unix. In one data path,
the write function unix_release_sock() atomically writes to
sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
unix_stream_sendmsg() does not read it atomically. Consequently, this
issue is causing the following KCSAN splat to occur:
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
value changed: 0x01 -> 0x03
The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
addressed a comparable issue in the past regarding sk->sk_shutdown.
However, it overlooked resolving this particular data path.
This patch only offending unix_stream_sendmsg() function, since the
other reads seem to be protected by unix_state_lock() as discussed in
CVE-2024-38596
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)
WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep.
We can't sleep in netpoll, it has interrupts disabled completely.
Strangely, gem_poll_controller() doesn't even poll the completions,
and instead acts as if an interrupt has fired so it just schedules
NAPI and exits. None of this has been necessary for years, since
netpoll invokes NAPI directly.
CVE-2024-38597
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md: fix resync softlockup when bitmap size is less than array size
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
<TASK>
md_bitmap_start_sync+0x6b/0xf0
raid10_sync_request+0x25c/0x1b40 [raid10]
md_do_sync+0x64b/0x1020
md_thread+0xa7/0x170
kthread+0xcf/0x100
ret_from_fork+0x30/0x50
ret_from_fork_asm+0x1a/0x30
And the detailed process is as follows:
md_do_sync
j = mddev->resync_min
while (j < max_sectors)
sectors = raid10_sync_request(mddev, j, &skipped)
if (!md_bitmap_start_sync(..., &sync_blocks))
// md_bitmap_start_sync set sync_blocks to 0
return sync_blocks + sectors_skippe;
// sectors = 0;
j += sectors;
// j never change
Root cause is that commit 301867b1c168 ("md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter") return early from
md_bitmap_get_counter(), without setting returned blocks.
Fix this problem by always set returned blocks from
md_bitmap_get_counter"(), as it used to be.
Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn't match array size still need to be fixed.
CVE-2024-38598
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix a race between readers and resize checks
The reader code in rb_get_reader_page() swaps a new reader page into the
ring buffer by doing cmpxchg on old->list.prev->next to point it to the
new page. Following that, if the operation is successful,
old->list.next->prev gets updated too. This means the underlying
doubly-linked list is temporarily inconsistent, page->prev->next or
page->next->prev might not be equal back to page for some page in the
ring buffer.
The resize operation in ring_buffer_resize() can be invoked in parallel.
It calls rb_check_pages() which can detect the described inconsistency
and stop further tracing:
[ 190.271762] ------------[ cut here ]------------
[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
[ 190.271789] Modules linked in: [...]
[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
[ 190.272023] Code: [...]
[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 190.272077] Call Trace:
[ 190.272098] <TASK>
[ 190.272189] ring_buffer_resize+0x2ab/0x460
[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0
[ 190.272206] tracing_resize_ring_buffer+0x65/0x90
[ 190.272216] tracing_entries_write+0x74/0xc0
[ 190.272225] vfs_write+0xf5/0x420
[ 190.272248] ksys_write+0x67/0xe0
[ 190.272256] do_syscall_64+0x82/0x170
[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 190.272373] RIP: 0033:0x7f1bd657d263
[ 190.272381] Code: [...]
[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
[ 190.272412] </TASK>
[ 190.272414] ---[ end trace 0000000000000000 ]---
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
trace_buffer has recording disabled. Recent commit d78ab792705c
("tracing: Stop current tracer when resizing buffer") causes that it is
now always the case which makes it more likely to experience this issue.
The window to hit this race is nonetheless very small. To help
reproducing it, one can add a delay loop in rb_get_reader_page():
ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
if (!ret)
goto spin;
for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */
__asm__ __volatile__ ("" : : : "memory");
rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
..
---truncated---
CVE-2024-38601
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix netif state handling
mlx5e_suspend cleans resources only if netif_device_present() returns
true. However, mlx5e_resume changes the state of netif, via
mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.
In the below case, the above leads to NULL-ptr Oops[1] and memory
leaks:
mlx5e_probe
_mlx5e_resume
mlx5e_attach_netdev
mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach()
register_netdev <-- failed for some reason.
ERROR_FLOW:
_mlx5e_suspend <-- netif_device_present return false, resources aren't freed :(
Hence, clean resources in this case as well.
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0010 [#1] SMP
CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:0x0
Code: Unable to access opcode bytes at0xffffffffffffffd6.
RSP: 0018:ffff888178aaf758 EFLAGS: 00010246
Call Trace:
<TASK>
? __die+0x20/0x60
? page_fault_oops+0x14c/0x3c0
? exc_page_fault+0x75/0x140
? asm_exc_page_fault+0x22/0x30
notifier_call_chain+0x35/0xb0
blocking_notifier_call_chain+0x3d/0x60
mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]
mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core]
mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib]
mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib]
__mlx5_ib_add+0x34/0xd0 [mlx5_ib]
mlx5r_probe+0xe1/0x210 [mlx5_ib]
? auxiliary_match_id+0x6a/0x90
auxiliary_bus_probe+0x38/0x80
? driver_sysfs_add+0x51/0x80
really_probe+0xc9/0x3e0
? driver_probe_device+0x90/0x90
__driver_probe_device+0x80/0x160
driver_probe_device+0x1e/0x90
__device_attach_driver+0x7d/0x100
bus_for_each_drv+0x80/0xd0
__device_attach+0xbc/0x1f0
bus_probe_device+0x86/0xa0
device_add+0x637/0x840
__auxiliary_device_add+0x3b/0xa0
add_adev+0xc9/0x140 [mlx5_core]
mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core]
mlx5_register_device+0x53/0xa0 [mlx5_core]
mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core]
mlx5_init_one+0x3b/0x60 [mlx5_core]
probe_one+0x44c/0x730 [mlx5_core]
local_pci_probe+0x3e/0x90
pci_device_probe+0xbf/0x210
? kernfs_create_link+0x5d/0xa0
? sysfs_do_create_link_sd+0x60/0xc0
really_probe+0xc9/0x3e0
? driver_probe_device+0x90/0x90
__driver_probe_device+0x80/0x160
driver_probe_device+0x1e/0x90
__device_attach_driver+0x7d/0x100
bus_for_each_drv+0x80/0xd0
__device_attach+0xbc/0x1f0
pci_bus_add_device+0x54/0x80
pci_iov_add_virtfn+0x2e6/0x320
sriov_enable+0x208/0x420
mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core]
sriov_numvfs_store+0xae/0x1a0
kernfs_fop_write_iter+0x10c/0x1a0
vfs_write+0x291/0x3c0
ksys_write+0x5f/0xe0
do_syscall_64+0x3d/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
CR2: 0000000000000000
---[ end trace 0000000000000000 ]---
CVE-2024-38608
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: timer: Set lower bound of start tick time
Currently ALSA timer doesn't have the lower limit of the start tick
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
for hrtimer. Such a situation may lead to an unexpected RCU stall,
where the callback repeatedly queuing the expire update, as reported
by fuzzer.
This patch introduces a sanity check of the timer start tick time, so
that the system returns an error when a too small start size is set.
As of this patch, the lower limit is hard-coded to 100us, which is
small enough but can still work somehow.
CVE-2024-38618
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb-storage: alauda: Check whether the media is initialized
The member "uzonesize" of struct alauda_info will remain 0
if alauda_init_media() fails, potentially causing divide errors
in alauda_read_data() and alauda_write_lba().
- Add a member "media_initialized" to struct alauda_info.
- Change a condition in alauda_check_media() to ensure the
first initialization.
- Add an error check for the return value of alauda_init_media().
CVE-2024-38619
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: stk1160: fix bounds checking in stk1160_copy_video()
The subtract in this condition is reversed. The ->length is the length
of the buffer. The ->bytesused is how many bytes we have copied thus
far. When the condition is reversed that means the result of the
subtraction is always negative but since it's unsigned then the result
is a very high positive value. That means the overflow check is never
true.
Additionally, the ->bytesused doesn't actually work for this purpose
because we're not writing to "buf->mem + buf->bytesused". Instead, the
math to calculate the destination where we are writing is a bit
involved. You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.
To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return. Otherwise, write up to buf->length bytes.
CVE-2024-38621
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
stm class: Fix a double free in stm_register_device()
The put_device(&stm->dev) call will trigger stm_device_release() which
frees "stm" so the vfree(stm) on the next line is a double free.
CVE-2024-38627
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
When the cpu5wdt module is removing, the origin code uses del_timer() to
de-activate the timer. If the timer handler is running, del_timer() could
not stop it and will return directly. If the port region is released by
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
to write into the region that is released, the use-after-free bug will
happen.
Change del_timer() to timer_shutdown_sync() in order that the timer handler
could be finished before the port region is released.
CVE-2024-38630
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: fix potential memory leak in vfio_intx_enable()
If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.
CVE-2024-38632
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
enic: Validate length of nl attributes in enic_set_vf_port
enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE
is of length PORT_PROFILE_MAX and that the nl attributes
IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.
These attributes are validated (in the function do_setlink in rtnetlink.c)
using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE
as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and
IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation
using the policy is for the max size of the attributes and not on exact
size so the length of these attributes might be less than the sizes that
enic_set_vf_port expects. This might cause an out of bands
read access in the memcpys of the data of these
attributes in enic_set_vf_port.
CVE-2024-38659
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/ap: Fix crash in AP internal function modify_bitmap()
A system crash like this
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
Fault in home space mode while using kernel ASCE.
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
Oops: 0038 ilc:3 [#1] PREEMPT SMP
Modules linked in: mlx5_ib ...
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
Hardware name: IBM 3931 A01 704 (LPAR)
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
0000014b75e7b600: 18b2 lr %r11,%r2
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
0000014b75e7b60c: a7680001 lhi %r6,1
0000014b75e7b610: 187b lr %r7,%r11
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
0000014b75e7b616: 18e9 lr %r14,%r9
Call Trace:
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
[<0000014b75e7b758>] apmask_store+0x68/0x140
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
[<0000014b75598524>] vfs_write+0x1b4/0x448
[<0000014b7559894c>] ksys_write+0x74/0x100
[<0000014b7618a440>] __do_syscall+0x268/0x328
[<0000014b761a3558>] system_call+0x70/0x98
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
Kernel panic - not syncing: Fatal exception: panic_on_oops
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
The fix is simple: use unsigned long values for the internal variables. The
correct checks are already in place in the function but a simple int for
the internal variables was used with the possibility to overflow.
CVE-2024-38661
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
known context") by error replaced spin_unlock_irqrestore() with
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
inconsistent lock state warning.
Use plain spin_{lock,unlock}() for sync_print_obj(), for
sync_debugfs_show() is already using spin_{lock,unlock}_irq().
CVE-2024-38780
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix uninit-value in p9_client_rpc()
Syzbot with the help of KMSAN reported the following error:
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
trace_9p_client_res include/trace/events/9p.h:146 [inline]
p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
vfs_get_tree+0xa7/0x570 fs/super.c:1797
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
path_mount+0x742/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
alloc_slab_page mm/slub.c:2175 [inline]
allocate_slab mm/slub.c:2338 [inline]
new_slab+0x2de/0x1400 mm/slub.c:2391
___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
__slab_alloc mm/slub.c:3610 [inline]
__slab_alloc_node mm/slub.c:3663 [inline]
slab_alloc_node mm/slub.c:3835 [inline]
kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
p9_tag_alloc net/9p/client.c:278 [inline]
p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
vfs_get_tree+0xa7/0x570 fs/super.c:1797
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
path_mount+0x742/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
will not be properly initialized. However, trace_9p_client_res()
ends up trying to print it out anyway before p9_client_rpc()
finishes.
Fix this issue by assigning default values to p9_fcall fields
such as 'tag' and (just in case KMSAN unearths something new) 'id'
during the tag allocation stage.
CVE-2024-39301
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: Handle err return when savagefb_check_var failed
The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
checks the value of pixclock to avoid divide-by-zero error. However
the function savagefb_probe doesn't handle the error return of
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
CVE-2024-39475
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well.
CVE-2024-39476
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
In function bond_option_arp_ip_targets_set(), if newval->string is an
empty string, newval->string+1 will point to the byte after the
string, causing an out-of-bound read.
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0xc1/0x5e0 mm/kasan/report.c:475
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
strlen+0x7d/0xa0 lib/string.c:418
__fortify_strlen include/linux/fortify-string.h:210 [inline]
in4_pton+0xa3/0x3f0 net/core/utils.c:130
bond_option_arp_ip_targets_set+0xc2/0x910
drivers/net/bonding/bond_options.c:1201
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
call_write_iter include/linux/fs.h:2020 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x96a/0xd80 fs/read_write.c:584
ksys_write+0x122/0x250 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace ]---
Fix it by adding a check of string length before using it.
CVE-2024-39487
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
to bug_table entries, and as a result the last entry in a bug table will
be ignored, potentially leading to an unexpected panic(). All prior
entries in the table will be handled correctly.
The arm64 ABI requires that struct fields of up to 8 bytes are
naturally-aligned, with padding added within a struct such that struct
are suitably aligned within arrays.
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
struct bug_entry {
signed int bug_addr_disp; // 4 bytes
signed int file_disp; // 4 bytes
unsigned short line; // 2 bytes
unsigned short flags; // 2 bytes
}
... with 12 bytes total, requiring 4-byte alignment.
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
struct bug_entry {
signed int bug_addr_disp; // 4 bytes
unsigned short flags; // 2 bytes
< implicit padding > // 2 bytes
}
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
padding, requiring 4-byte alginment.
When we create a bug_entry in assembly, we align the start of the entry
to 4 bytes, which implicitly handles padding for any prior entries.
However, we do not align the end of the entry, and so when
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
bytes.
For the main kernel image this is not a problem as find_bug() doesn't
depend on the trailing padding bytes when searching for entries:
for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
if (bugaddr == bug_addr(bug))
return bug;
However for modules, module_bug_finalize() depends on the trailing
bytes when calculating the number of entries:
mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
... and as the last bug_entry lacks the necessary padding bytes, this entry
will not be counted, e.g. in the case of a single entry:
sechdrs[i].sh_size == 6
sizeof(struct bug_entry) == 8;
sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
Consequently module_find_bug() will miss the last bug_entry when it does:
for (i = 0; i < mod->num_bugs; ++i, ++bug)
if (bugaddr == bug_addr(bug))
goto out;
... which can lead to a kenrel panic due to an unhandled bug.
This can be demonstrated with the following module:
static int __init buginit(void)
{
WARN(1, "hello\n");
return 0;
}
static void __exit bugexit(void)
{
}
module_init(buginit);
module_exit(bugexit);
MODULE_LICENSE("GPL");
... which will trigger a kernel panic when loaded:
------------[ cut here ]------------
hello
Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: hello(O+)
CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8
Hardware name: linux,dummy-virt (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : buginit+0x18/0x1000 [hello]
lr : buginit+0x18/0x1000 [hello]
sp : ffff800080533ae0
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
Call trace:
buginit+0x18/0x1000 [hello]
do_one_initcall+0x80/0x1c8
do_init_module+0x60/0x218
load_module+0x1ba4/0x1d70
__do_sys_init_module+0x198/0x1d0
__arm64_sys_init_module+0x1c/0x28
invoke_syscall+0x48/0x114
el0_svc
---truncated---
CVE-2024-39488
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix memleak in seg6_hmac_init_algo
seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it's going to leak all that memory and the crypto tfms.
Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly.
CVE-2024-39489
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix missing sk_buff release in seg6_input_core
The seg6_input() function is responsible for adding the SRH into a
packet, delegating the operation to the seg6_input_core(). This function
uses the skb_cow_head() to ensure that there is sufficient headroom in
the sk_buff for accommodating the link-layer header.
In the event that the skb_cow_header() function fails, the
seg6_input_core() catches the error but it does not release the sk_buff,
which will result in a memory leak.
This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due
to headroom too small after SRH push") and persists even after commit
7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),
where the entire seg6_input() code was refactored to deal with netfilter
hooks.
The proposed patch addresses the identified memory leak by requiring the
seg6_input_core() function to release the sk_buff in the event that
skb_cow_head() fails.
CVE-2024-39490
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ima: Fix use-after-free on a dentry's dname.name
->d_name.name can change on rename and the earlier value can be freed;
there are conditions sufficient to stabilize it (->d_lock on dentry,
->d_lock on its parent, ->i_rwsem exclusive on the parent's inode,
rename_lock), but none of those are met at any of the sites. Take a stable
snapshot of the name instead.
CVE-2024-39494
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
vmci: prevent speculation leaks by sanitizing event in event_deliver()
Coverity spotted that event_msg is controlled by user-space,
event_msg->event_data.event is passed to event_deliver() and used
as an index without sanitization.
This change ensures that the event index is sanitized to mitigate any
possibility of speculative information leaks.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Only compile tested, no access to HW.
CVE-2024-39499
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-39501
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
but then it is unconditionally passed to skb_add_rx_frag() which looks
strange and could lead to null pointer dereference.
lio_vf_rep_copy_packet() call trace looks like:
octeon_droq_process_packets
octeon_droq_fast_process_packets
octeon_droq_dispatch_pkt
octeon_create_recv_info
...search in the dispatch_list...
->disp_fn(rdisp->rinfo, ...)
lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
In this path there is no code which sets pg_info->page to NULL.
So this check looks unneeded and doesn't solve potential problem.
But I guess the author had reason to add a check and I have no such card
and can't do real test.
In addition, the code in the function liquidio_push_packet() in
liquidio/lio_core.c does exactly the same.
Based on this, I consider the most acceptable compromise solution to
adjust this issue by moving skb_add_rx_frag() into conditional scope.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-39506
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash problem in concurrent scenario
When link status change, the nic driver need to notify the roce
driver to handle this event, but at this time, the roce driver
may uninit, then cause kernel crash.
To fix the problem, when link status change, need to check
whether the roce registered, and when uninit, need to wait link
update finish.
CVE-2024-39507
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying
to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
...
value &= m;
...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.
[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
<TASK>
__usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
CVE-2024-39509
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
The “ipaddress” module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as “globally reachable” or “private”. This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn't be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.
CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.
CVE-2024-4032
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
low
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
There is a potential out-of-bounds access when using test_bit() on a single
word. The test_bit() and set_bit() functions operate on long values, and
when testing or setting a single word, they can exceed the word
boundary. KASAN detects this issue and produces a dump:
BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas
Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965
For full log, please look at [1].
Make the allocation at least the size of sizeof(unsigned long) so that
set_bit() and test_bit() have sufficient room for read/write operations
without overwriting unallocated memory.
[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
CVE-2024-40901
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
The syzbot fuzzer found that the interrupt-URB completion callback in
the cdc-wdm driver was taking too long, and the driver's immediate
resubmission of interrupt URBs with -EPROTO status combined with the
dummy-hcd emulation to cause a CPU lockup:
cdc_wdm 1-1:1.0: nonzero urb status received: -71
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
CPU#0 Utilization every 4s during lockup:
#1: 98% system, 0% softirq, 3% hardirq, 0% idle
#2: 98% system, 0% softirq, 3% hardirq, 0% idle
#3: 98% system, 0% softirq, 3% hardirq, 0% idle
#4: 98% system, 0% softirq, 3% hardirq, 0% idle
#5: 98% system, 1% softirq, 3% hardirq, 0% idle
Modules linked in:
irq event stamp: 73096
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Testing showed that the problem did not occur if the two error
messages -- the first two lines above -- were removed; apparently adding
material to the kernel log takes a surprisingly large amount of time.
In any case, the best approach for preventing these lockups and to
avoid spamming the log with thousands of error messages per second is
to ratelimit the two dev_err() calls. Therefore we replace them with
dev_err_ratelimited().
CVE-2024-40904
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to
synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from
softirq context. However using only spin_lock() to get sta->ps_lock in
ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute
on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to
take this same lock ending in deadlock. Below is an example of rcu stall
that arises in such situation.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996
rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4)
CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742
Hardware name: RPT (r1) (DT)
pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : queued_spin_lock_slowpath+0x58/0x2d0
lr : invoke_tx_handlers_early+0x5b4/0x5c0
sp : ffff00001ef64660
x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8
x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000
x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000
x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000
x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80
x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da
x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440
x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880
x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8
Call trace:
queued_spin_lock_slowpath+0x58/0x2d0
ieee80211_tx+0x80/0x12c
ieee80211_tx_pending+0x110/0x278
tasklet_action_common.constprop.0+0x10c/0x144
tasklet_action+0x20/0x28
_stext+0x11c/0x284
____do_softirq+0xc/0x14
call_on_irq_stack+0x24/0x34
do_softirq_own_stack+0x18/0x20
do_softirq+0x74/0x7c
__local_bh_enable_ip+0xa0/0xa4
_ieee80211_wake_txqs+0x3b0/0x4b8
__ieee80211_wake_queue+0x12c/0x168
ieee80211_add_pending_skbs+0xec/0x138
ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480
ieee80211_mps_sta_status_update.part.0+0xd8/0x11c
ieee80211_mps_sta_status_update+0x18/0x24
sta_apply_parameters+0x3bc/0x4c0
ieee80211_change_station+0x1b8/0x2dc
nl80211_set_station+0x444/0x49c
genl_family_rcv_msg_doit.isra.0+0xa4/0xfc
genl_rcv_msg+0x1b0/0x244
netlink_rcv_skb+0x38/0x10c
genl_rcv+0x34/0x48
netlink_unicast+0x254/0x2bc
netlink_sendmsg+0x190/0x3b4
____sys_sendmsg+0x1e8/0x218
___sys_sendmsg+0x68/0x8c
__sys_sendmsg+0x44/0x84
__arm64_sys_sendmsg+0x20/0x28
do_el0_svc+0x6c/0xe8
el0_svc+0x14/0x48
el0t_64_sync_handler+0xb0/0xb4
el0t_64_sync+0x14c/0x150
Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise
on the same CPU that is holding the lock.
CVE-2024-40912
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: disable rx data ring on dma allocation failure
When vmxnet3_rq_create() fails to allocate memory for rq->data_ring.base,
the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset
rq->data_ring.desc_size for the data ring that failed, which presumably
causes the hypervisor to reference it on packet reception.
To fix this bug, rq->data_ring.desc_size needs to be set to 0 to tell
the hypervisor to disable this feature.
[ 95.436876] kernel BUG at net/core/skbuff.c:207!
[ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1
[ 95.441558] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
[ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f
[ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50
ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9
ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24
[ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246
[ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f
[ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f
[ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60
[ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000
[ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0
[ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000
[ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0
[ 95.459791] Call Trace:
[ 95.460515] <IRQ>
[ 95.461180] ? __die_body.cold+0x19/0x27
[ 95.462150] ? die+0x2e/0x50
[ 95.462976] ? do_trap+0xca/0x110
[ 95.463973] ? do_error_trap+0x6a/0x90
[ 95.464966] ? skb_panic+0x4d/0x4f
[ 95.465901] ? exc_invalid_op+0x50/0x70
[ 95.466849] ? skb_panic+0x4d/0x4f
[ 95.467718] ? asm_exc_invalid_op+0x1a/0x20
[ 95.468758] ? skb_panic+0x4d/0x4f
[ 95.469655] skb_put.cold+0x10/0x10
[ 95.470573] vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]
[ 95.471853] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]
[ 95.473185] __napi_poll+0x2b/0x160
[ 95.474145] net_rx_action+0x2c6/0x3b0
[ 95.475115] handle_softirqs+0xe7/0x2a0
[ 95.476122] __irq_exit_rcu+0x97/0xb0
[ 95.477109] common_interrupt+0x85/0xa0
[ 95.478102] </IRQ>
[ 95.478846] <TASK>
[ 95.479603] asm_common_interrupt+0x26/0x40
[ 95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20
[ 95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 <e9> 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
[ 95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246
[ 95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000
[ 95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001
[ 95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3
[ 95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260
[ 95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000
[ 95.495035] acpi_safe_halt+0x14/0x20
[ 95.496127] acpi_idle_do_entry+0x2f/0x50
[ 95.497221] acpi_idle_enter+0x7f/0xd0
[ 95.498272] cpuidle_enter_state+0x81/0x420
[ 95.499375] cpuidle_enter+0x2d/0x40
[ 95.500400] do_idle+0x1e5/0x240
[ 95.501385] cpu_startup_entry+0x29/0x30
[ 95.502422] start_secondary+0x11c/0x140
[ 95.503454] common_startup_64+0x13e/0x141
[ 95.504466] </TASK>
[ 95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4
nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip
---truncated---
CVE-2024-40923
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
In some versions of cfg80211, the ssids poinet might be a valid one even
though n_ssids is 0. Accessing the pointer in this case will cuase an
out-of-bound access. Fix this by checking n_ssids first.
CVE-2024-40929
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/exynos/vidi: fix memory leak in .get_modes()
The duplicated EDID is never freed. Fix it.
CVE-2024-40932
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gve: Clear napi->skb before dev_kfree_skb_any()
gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it
is freed with dev_kfree_skb_any(). This can result in a subsequent call
to napi_get_frags returning a dangling pointer.
Fix this by clearing napi->skb before the skb is freed.
CVE-2024-40937
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't read past the mfuart notifcation
In case the firmware sends a notification that claims it has more data
than it has, we will read past that was allocated for the notification.
Remove the print of the buffer, we won't see it by default. If needed,
we can see the content with tracing.
This was reported by KFENCE.
CVE-2024-40941
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
The hwmp code use objects of type mesh_preq_queue, added to a list in
ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath
gets deleted, ex mesh interface is removed, the entries in that list will
never get cleaned. Fix this by flushing all corresponding items of the
preq_queue in mesh_path_flush_pending().
This should take care of KASAN reports like this:
unreferenced object 0xffff00000668d800 (size 128):
comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s)
hex dump (first 32 bytes):
00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....
8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>...........
backtrace:
[<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
[<00000000049bd418>] kmalloc_trace+0x34/0x80
[<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
[<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
[<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
[<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
[<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
[<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
[<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
[<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
[<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
[<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
[<00000000b36425d1>] worker_thread+0x9c/0x634
[<0000000005852dd5>] kthread+0x1bc/0x1c4
[<000000005fccd770>] ret_from_fork+0x10/0x20
unreferenced object 0xffff000009051f00 (size 128):
comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s)
hex dump (first 32 bytes):
90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....
36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy.....
backtrace:
[<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
[<00000000049bd418>] kmalloc_trace+0x34/0x80
[<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
[<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
[<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
[<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
[<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
[<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
[<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
[<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
[<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
[<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
[<00000000b36425d1>] worker_thread+0x9c/0x634
[<0000000005852dd5>] kthread+0x1bc/0x1c4
[<000000005fccd770>] ret_from_fork+0x10/0x20
CVE-2024-40942
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix races between hole punching and AIO+DIO
After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",
fstests/generic/300 become from always failed to sometimes failed:
========================================================================
[ 473.293420 ] run fstests generic/300
[ 475.296983 ] JBD2: Ignoring recovery information on journal
[ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
[ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found
[ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
[ 494.292018 ] OCFS2: File system is now read-only.
[ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30
[ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3
fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072
=========================================================================
In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten
extents to a list. extents are also inserted into extent tree in
ocfs2_write_begin_nolock. Then another thread call fallocate to puch a
hole at one of the unwritten extent. The extent at cpos was removed by
ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list
found there is no such extent at the cpos.
T1 T2 T3
inode lock
...
insert extents
...
inode unlock
ocfs2_fallocate
__ocfs2_change_file_space
inode lock
lock ip_alloc_sem
ocfs2_remove_inode_range inode
ocfs2_remove_btree_range
ocfs2_remove_extent
^---remove the extent at cpos 78723
...
unlock ip_alloc_sem
inode unlock
ocfs2_dio_end_io
ocfs2_dio_end_io_write
lock ip_alloc_sem
ocfs2_mark_extent_written
ocfs2_change_extent_flag
ocfs2_search_extent_list
^---failed to find extent
...
unlock ip_alloc_sem
In most filesystems, fallocate is not compatible with racing with AIO+DIO,
so fix it by adding to wait for all dio before fallocate/punch_hole like
ext4.
CVE-2024-40943
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the
loads and stores are atomic. In the extremely unlikely scenario the
compiler tears the stores, it's theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:
CPU0 CPU1
last_boosted_vcpu = 0xff;
(last_boosted_vcpu = 0x100)
last_boosted_vcpu[15:8] = 0x01;
i = (last_boosted_vcpu = 0x1ff)
last_boosted_vcpu[7:0] = 0x00;
vcpu = kvm->vcpu_array[0x1ff];
As detected by KCSAN:
BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]
write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
__se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
__x64_sys_ioctl (fs/ioctl.c:890)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
__se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
__x64_sys_ioctl (fs/ioctl.c:890)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
value changed: 0x00000012 -> 0x00000000
CVE-2024-40953
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
syzbot reported:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
RSP: 0018:ffffc90000117378 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
process_scheduled_works kernel/workqueue.c:3312 [inline]
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
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-40959
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: lpi2c: Avoid calling clk_get_rate during transfer
Instead of repeatedly calling clk_get_rate for each transfer, lock
the clock rate and cache the value.
A deadlock has been observed while adding tlv320aic32x4 audio codec to
the system. When this clock provider adds its clock, the clk mutex is
locked already, it needs to access i2c, which in return needs the mutex
for clk_get_rate as well.
CVE-2024-40965
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tty: add the option to have a tty reject a new ldisc
... and use it to limit the virtual terminals to just N_TTY. They are
kind of special, and in particular, the "con_write()" routine violates
the "writes cannot sleep" rule that some ldiscs rely on.
This avoids the
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659
when N_GSM has been attached to a virtual console, and gsmld_write()
calls con_write() while holding a spinlock, and con_write() then tries
to get the console lock.
CVE-2024-40966
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: imx: Introduce timeout when waiting on transmitter empty
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
deadlock.
In case of the timeout, there is not much we can do, so we simply ignore
the transmitter state and optimistically try to continue.
CVE-2024-40967
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedi: Fix crash while reading debugfs attribute
The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
on a __user pointer, which results into the crash.
To fix this issue, use a small local stack buffer for sprintf() and then
call simple_read_from_buffer(), which in turns make the copy_to_user()
call.
BUG: unable to handle page fault for address: 00007f4801111000
PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
Oops: 0002 [#1] PREEMPT SMP PTI
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
RIP: 0010:memcpy_orig+0xcd/0x130
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? __die_body+0x1a/0x60
? page_fault_oops+0x183/0x510
? exc_page_fault+0x69/0x150
? asm_exc_page_fault+0x22/0x30
? memcpy_orig+0xcd/0x130
vsnprintf+0x102/0x4c0
sprintf+0x51/0x80
qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
full_proxy_read+0x50/0x80
vfs_read+0xa5/0x2e0
? folio_add_new_anon_rmap+0x44/0xa0
? set_pte_at+0x15/0x30
? do_pte_missing+0x426/0x7f0
ksys_read+0xa5/0xe0
do_syscall_64+0x58/0x80
? __count_memcg_events+0x46/0x90
? count_memcg_event_mm+0x3d/0x60
? handle_mm_fault+0x196/0x2f0
? do_user_addr_fault+0x267/0x890
? exc_page_fault+0x69/0x150
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f4800f20b4d
CVE-2024-40978
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-40982
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid
"Info: mapping multiple BARs. Your kernel is fine.""). The initial
purpose of this commit was to stop memory mappings for operation
regions from overlapping page boundaries, as it can trigger warnings
if different page attributes are present.
However, it was found that when this situation arises, mapping
continues until the boundary's end, but there is still an attempt to
read/write the entire length of the map, leading to a NULL pointer
deference. For example, if a four-byte mapping request is made but
only one byte is mapped because it hits the current page boundary's
end, a four-byte read/write attempt is still made, resulting in a NULL
pointer deference.
Instead, map the entire length, as the ACPI specification does not
mandate that it must be within the same page boundary. It is
permissible for it to be mapped across different regions.
CVE-2024-40984
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix UBSAN warning in kv_dpm.c
Adds bounds check for sumo_vid_mapping_entry.
CVE-2024-40987
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix UBSAN warning in kv_dpm.c
Adds bounds check for sumo_vid_mapping_entry.
CVE-2024-40988
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Add check for srq max_sge attribute
max_sge attribute is passed by the user, and is inserted and used
unchecked, so verify that the value doesn't exceed maximum allowed value
before using it.
CVE-2024-40990
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
syzbot found hanging tasks waiting on rtnl_lock [1]
A reproducer is available in the syzbot bug.
When a request to add multiple actions with the same index is sent, the
second request will block forever on the first request. This holds
rtnl_lock, and causes tasks to hang.
Return -EAGAIN to prevent infinite looping, while keeping documented
behavior.
[1]
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
Workqueue: events_power_efficient reg_check_chans_work
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5409 [inline]
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
__schedule_loop kernel/sched/core.c:6823 [inline]
schedule+0xe7/0x350 kernel/sched/core.c:6838
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
wiphy_lock include/net/cfg80211.h:5953 [inline]
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481
CVE-2024-40995
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()
In the following concurrency we will access the uninitialized rs->lock:
ext4_fill_super
ext4_register_sysfs
// sysfs registered msg_ratelimit_interval_ms
// Other processes modify rs->interval to
// non-zero via msg_ratelimit_interval_ms
ext4_orphan_cleanup
ext4_msg(sb, KERN_INFO, "Errors on filesystem, "
__ext4_msg
___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state)
if (!rs->interval) // do nothing if interval is 0
return 1;
raw_spin_trylock_irqsave(&rs->lock, flags)
raw_spin_trylock(lock)
_raw_spin_trylock
__raw_spin_trylock
spin_acquire(&lock->dep_map, 0, 1, _RET_IP_)
lock_acquire
__lock_acquire
register_lock_class
assign_lock_key
dump_stack();
ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10);
raw_spin_lock_init(&rs->lock);
// init rs->lock here
and get the following dump_stack:
=========================================================
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504
[...]
Call Trace:
dump_stack_lvl+0xc5/0x170
dump_stack+0x18/0x30
register_lock_class+0x740/0x7c0
__lock_acquire+0x69/0x13a0
lock_acquire+0x120/0x450
_raw_spin_trylock+0x98/0xd0
___ratelimit+0xf6/0x220
__ext4_msg+0x7f/0x160 [ext4]
ext4_orphan_cleanup+0x665/0x740 [ext4]
__ext4_fill_super+0x21ea/0x2b10 [ext4]
ext4_fill_super+0x14d/0x360 [ext4]
[...]
=========================================================
Normally interval is 0 until s_msg_ratelimit_state is initialized, so
___ratelimit() does nothing. But registering sysfs precedes initializing
rs->lock, so it is possible to change rs->interval to a non-zero value
via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is
uninitialized, and then a call to ext4_msg triggers the problem by
accessing an uninitialized rs->lock. Therefore register sysfs after all
initializations are complete to avoid such problems.
CVE-2024-40998
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ena: Add validation for completion descriptors consistency
Validate that `first` flag is set only for the first
descriptor in multi-buffer packets.
In case of an invalid descriptor, a reset will occur.
A new reset reason for RX data corruption has been added.
CVE-2024-40999
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
netpoll: Fix race condition in netpoll_owner_active
KCSAN detected a race condition in netpoll:
BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
<snip>
read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:
netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)
netpoll_send_udp (net/core/netpoll.c:?)
<snip>
value changed: 0x0000000a -> 0xffffffff
This happens because netpoll_owner_active() needs to check if the
current CPU is the owner of the lock, touching napi->poll_owner
non atomically. The ->poll_owner field contains the current CPU holding
the lock.
Use an atomic read to check if the poll owner is the current CPU.
CVE-2024-41005
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with
do_lock_file_wait().
However, LSMs can allow the first do_lock_file_wait() that created the lock
while denying the second do_lock_file_wait() that tries to remove the lock.
Separately, posix_lock_file() could also fail to
remove a lock due to GFP_KERNEL allocation failure (when splitting a range
in the middle).
After the bug has been triggered, use-after-free reads will occur in
lock_get_status() when userspace reads /proc/locks. This can likely be used
to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to
reliably get rid of POSIX locks associated with the given file and
files_struct and is also used by filp_flush().
CVE-2024-41012
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xfs: add bounds checking to xlog_recover_process_data
There is a lack of verification of the space occupied by fixed members
of xlog_op_header in the xlog_recover_process_data.
We can create a crafted image to trigger an out of bounds read by
following these steps:
1) Mount an image of xfs, and do some file operations to leave records
2) Before umounting, copy the image for subsequent steps to simulate
abnormal exit. Because umount will ensure that tail_blk and
head_blk are the same, which will result in the inability to enter
xlog_recover_process_data
3) Write a tool to parse and modify the copied image in step 2
4) Make the end of the xlog_op_header entries only 1 byte away from
xlog_rec_header->h_size
5) xlog_rec_header->h_num_logops++
6) Modify xlog_rec_header->h_crc
Fix:
Add a check to make sure there is sufficient space to access fixed members
of xlog_op_header.
CVE-2024-41014
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_check_dir_entry()
This adds sanity checks for ocfs2_dir_entry to make sure all members of
ocfs2_dir_entry don't stray beyond valid memory region.
CVE-2024-41015
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
xattr in ocfs2 maybe 'non-indexed', which saved with additional space
requested. It's better to check if the memory is out of bound before
memcmp, although this possibility mainly comes from crafted poisonous
images.
CVE-2024-41016
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
filelock: Fix fcntl/close race recovery compat path
When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
fcntl/close race is detected"), I missed that there are two copies of the
code I was patching: The normal version, and the version for 64-bit offsets
on 32-bit kernels.
Thanks to Greg KH for stumbling over this while doing the stable
backport...
Apply exactly the same fix to the compat path for 32-bit kernels.
CVE-2024-41020
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below)
caused by our assumption that the reserved bits in an endpoint
descriptor's bEndpointAddress field will always be 0. As a result of
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
other routines as well) may believe that two descriptors are for
distinct endpoints, even though they have the same direction and
endpoint number. This can lead to confusion, including the bug
identified by syzbot (two descriptors with matching endpoint numbers
and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
specs say these bits are "Reserved, reset to zero".) This requires us
to make a copy of the descriptor earlier in usb_parse_endpoint() and
use the copy instead of the original when checking for duplicates.
CVE-2024-41035
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ppp: reject claimed-as-LCP but actually malformed packets
Since 'ppp_async_encode()' assumes valid LCP packets (with code
from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that
LCP packet has an actual body beyond PPP_LCP header bytes, and
reject claimed-as-LCP but actually malformed data otherwise.
CVE-2024-41044
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
skmsg: Skip zero length skb in sk_msg_recvmsg
When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch
platform, the following kernel panic occurs:
[...]
Oops[#1]:
CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18
Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018
... ...
ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560
ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 0000000c (PPLV0 +PIE +PWE)
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
BADV: 0000000000000040
PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack
Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)
Stack : ...
Call Trace:
[<9000000004162774>] copy_page_to_iter+0x74/0x1c0
[<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560
[<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0
[<90000000049aae34>] inet_recvmsg+0x54/0x100
[<900000000481ad5c>] sock_recvmsg+0x7c/0xe0
[<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0
[<900000000481e27c>] sys_recvfrom+0x1c/0x40
[<9000000004c076ec>] do_syscall+0x8c/0xc0
[<9000000003731da4>] handle_syscall+0xc4/0x160
Code: ...
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Fatal exception
Kernel relocated by 0x3510000
.text @ 0x9000000003710000
.data @ 0x9000000004d70000
.bss @ 0x9000000006469400
---[ end Kernel panic - not syncing: Fatal exception ]---
[...]
This crash happens every time when running sockmap_skb_verdict_shutdown
subtest in sockmap_basic.
This crash is because a NULL pointer is passed to page_address() in the
sk_msg_recvmsg(). Due to the different implementations depending on the
architecture, page_address(NULL) will trigger a panic on Loongarch
platform but not on x86 platform. So this bug was hidden on x86 platform
for a while, but now it is exposed on Loongarch platform. The root cause
is that a zero length skb (skb->len == 0) was put on the queue.
This zero length skb is a TCP FIN packet, which was sent by shutdown(),
invoked in test_sockmap_skb_verdict_shutdown():
shutdown(p1, SHUT_WR);
In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no
page is put to this sge (see sg_set_page in sg_set_page), but this empty
sge is queued into ingress_msg list.
And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by
sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it
to kmap_local_page() and to page_address(), then kernel panics.
To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),
if copy is zero, that means it's a zero length skb, skip invoking
copy_page_to_iter(). We are using the EFAULT return triggered by
copy_page_to_iter to check for is_fin in tcp_bpf.c.
CVE-2024-41048
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix uninit-value in copy_name
[syzbot reported]
BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160
sized_strscpy+0xc4/0x160
copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411
hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750
vfs_listxattr fs/xattr.c:493 [inline]
listxattr+0x1f3/0x6b0 fs/xattr.c:840
path_listxattr fs/xattr.c:864 [inline]
__do_sys_listxattr fs/xattr.c:876 [inline]
__se_sys_listxattr fs/xattr.c:873 [inline]
__x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3877 [inline]
slab_alloc_node mm/slub.c:3918 [inline]
kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065
kmalloc include/linux/slab.h:628 [inline]
hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699
vfs_listxattr fs/xattr.c:493 [inline]
listxattr+0x1f3/0x6b0 fs/xattr.c:840
path_listxattr fs/xattr.c:864 [inline]
__do_sys_listxattr fs/xattr.c:876 [inline]
__se_sys_listxattr fs/xattr.c:873 [inline]
__x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Fix]
When allocating memory to strbuf, initialize memory to 0.
CVE-2024-41059
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check bo_va->bo is non-NULL before using it
The call to radeon_vm_clear_freed might clear bo_va->bo, so
we have to check it before dereferencing it.
CVE-2024-41060
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bluetooth/l2cap: sync sock recv cb and release
The problem occurs between the system call to close the sock and hci_rx_work,
where the former releases the sock and the latter accesses it without lock protection.
CPU0 CPU1
---- ----
sock_close hci_rx_work
l2cap_sock_release hci_acldata_packet
l2cap_sock_kill l2cap_recv_frame
sk_free l2cap_conless_channel
l2cap_sock_recv_cb
If hci_rx_work processes the data that needs to be received before the sock is
closed, then everything is normal; Otherwise, the work thread may access the
released sock when receiving data.
Add a chan mutex in the rx callback of the sock to achieve synchronization between
the sock release and recv cb.
Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.
CVE-2024-41062
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
syzbot is reporting that calling hci_release_dev() from hci_error_reset()
due to hci_dev_put() from hci_error_reset() can cause deadlock at
destroy_workqueue(), for hci_error_reset() is called from
hdev->req_workqueue which destroy_workqueue() needs to flush.
We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are
queued into hdev->workqueue and hdev->{power_on,error_reset} which are
queued into hdev->req_workqueue are no longer running by the moment
destroy_workqueue(hdev->workqueue);
destroy_workqueue(hdev->req_workqueue);
are called from hci_release_dev().
Call cancel_work_sync() on these work items from hci_unregister_dev()
as soon as hdev->list is removed from hci_dev_list.
CVE-2024-41063
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/eeh: avoid possible crash when edev->pdev changes
If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
will change and can cause a crash, hold the PCI rescan/remove lock
while taking a copy of edev->pdev->bus.
CVE-2024-41064
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Add tx check to prevent skb leak
Below is a summary of how the driver stores a reference to an skb during
transmit:
tx_buff[free_map[consumer_index]]->skb = new_skb;
free_map[consumer_index] = IBMVNIC_INVALID_MAP;
consumer_index ++;
Where variable data looks like this:
free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]
consumer_index^
tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]
The driver has checks to ensure that free_map[consumer_index] pointed to
a valid index but there was no check to ensure that this index pointed
to an unused/null skb address. So, if, by some chance, our free_map and
tx_buff lists become out of sync then we were previously risking an
skb memory leak. This could then cause tcp congestion control to stop
sending packets, eventually leading to ETIMEDOUT.
Therefore, add a conditional to ensure that the skb address is null. If
not then warn the user (because this is still a bug that should be
patched) and free the old pointer to prevent memleak/tcp problems.
CVE-2024-41066
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Fix sclp_init() cleanup on failure
If sclp_init() fails it only partially cleans up: if there are multiple
failing calls to sclp_init() sclp_state_change_event will be added several
times to sclp_reg_list, which results in the following warning:
------------[ cut here ]------------
list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.
WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3
Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
...
Call Trace:
[<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8
([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8)
[<000003ffe0a8d37e>] sclp_init+0x40e/0x450
[<000003ffe00009f2>] do_one_initcall+0x42/0x1e0
[<000003ffe15b77a6>] do_initcalls+0x126/0x150
[<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8
[<000003ffe0d6650e>] kernel_init+0x2e/0x180
[<000003ffe000301c>] __ret_from_fork+0x3c/0x60
[<000003ffe0d759ca>] ret_from_fork+0xa/0x30
Fix this by removing sclp_state_change_event from sclp_reg_list when
sclp_init() fails.
CVE-2024-41068
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
It looks up `stt` from tablefd, but then continues to use it after doing
fdput() on the returned fd. After the fdput() the tablefd is free to be
closed by another thread. The close calls kvm_spapr_tce_release() and
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
Although there are calls to rcu_read_lock() in
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
the UAF, because `stt` is used outside the locked regions.
With an artifcial delay after the fdput() and a userspace program which
triggers the race, KASAN detects the UAF:
BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
Call Trace:
dump_stack_lvl+0xb4/0x108 (unreliable)
print_report+0x2b4/0x6ec
kasan_report+0x118/0x2b0
__asan_load4+0xb8/0xd0
kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
kvm_vfio_set_attr+0x524/0xac0 [kvm]
kvm_device_ioctl+0x144/0x240 [kvm]
sys_ioctl+0x62c/0x1810
system_call_exception+0x190/0x440
system_call_vectored_common+0x15c/0x2ec
...
Freed by task 0:
...
kfree+0xec/0x3e0
release_spapr_tce_table+0xd4/0x11c [kvm]
rcu_core+0x568/0x16a0
handle_softirqs+0x23c/0x920
do_softirq_own_stack+0x6c/0x90
do_softirq_own_stack+0x58/0x90
__irq_exit_rcu+0x218/0x2d0
irq_exit+0x30/0x80
arch_local_irq_restore+0x128/0x230
arch_local_irq_enable+0x1c/0x30
cpuidle_enter_state+0x134/0x5cc
cpuidle_enter+0x6c/0xb0
call_cpuidle+0x7c/0x100
do_idle+0x394/0x410
cpu_startup_entry+0x60/0x70
start_secondary+0x3fc/0x410
start_secondary_prolog+0x10/0x14
Fix it by delaying the fdput() until `stt` is no longer in use, which
is effectively the entire function. To keep the patch minimal add a call
to fdput() at each of the existing return paths. Future work can convert
the function to goto or __cleanup style cleanup.
With the fix in place the test case no longer triggers the UAF.
CVE-2024-41070
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-41071
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
In 'cfg80211_wext_siwscan()', add extra check whether number of
channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed
IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.
CVE-2024-41072
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before
a new special payload is added, a double free will result. Clear the
RQF_SPECIAL_LOAD when the request is cleaned.
CVE-2024-41073
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix quota root leak after quota disable failure
If during the quota disable we fail when cleaning the quota tree or when
deleting the root from the root tree, we jump to the 'out' label without
ever dropping the reference on the quota root, resulting in a leak of the
root since fs_info->quota_root is no longer pointing to the root (we have
set it to NULL just before those steps).
Fix this by always doing a btrfs_put_root() call under the 'out' label.
This is a problem that exists since qgroups were first added in 2012 by
commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but
back then we missed a kfree on the quota root and free_extent_buffer()
calls on its root and commit root nodes, since back then roots were not
yet reference counted.
CVE-2024-41078
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvmet: always initialize cqe.result
The spec doesn't mandate that the first two double words (aka results)
for the command queue entry need to be set to 0 when they are not
used (not specified). Though, the target implemention returns 0 for TCP
and FC but not for RDMA.
Let's make RDMA behave the same and thus explicitly initializing the
result field. This prevents leaking any data from the stack.
CVE-2024-41079
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ila: block BH in ila_output()
As explained in commit 1378817486d6 ("tipc: block BH
before using dst_cache"), net/core/dst_cache.c
helpers need to be called with BH disabled.
ila_output() is called from lwtunnel_output()
possibly from process context, and under rcu_read_lock().
We might be interrupted by a softirq, re-enter ila_output()
and corrupt dst_cache data structures.
Fix the race by using local_bh_disable().
CVE-2024-41081
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-fabrics: use reserved tag for reg read/write command
In some scenarios, if too many commands are issued by nvme command in
the same time by user tasks, this may exhaust all tags of admin_q. If
a reset (nvme reset or IO timeout) occurs before these commands finish,
reconnect routine may fail to update nvme regs due to insufficient tags,
which will cause kernel hang forever. In order to workaround this issue,
maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved
tags. This maybe safe for nvmf:
1. For the disable ctrl path, we will not issue connect command
2. For the enable ctrl / fw activate path, since connect and reg_xx()
are called serially.
So the reserved tags may still be enough while reg_xx() use reserved tags.
CVE-2024-41082
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix double free on error
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:
kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? __die_body.cold+0x19/0x27
? die+0x2e/0x50
? do_trap+0xca/0x110
? do_error_trap+0x6a/0x90
? kfree+0x2cf/0x2f0
? exc_invalid_op+0x50/0x70
? kfree+0x2cf/0x2f0
? asm_exc_invalid_op+0x1a/0x20
? ata_host_alloc+0xf5/0x120 [libata]
? ata_host_alloc+0xf5/0x120 [libata]
? kfree+0x2cf/0x2f0
ata_host_alloc+0xf5/0x120 [libata]
ata_host_alloc_pinfo+0x14/0xa0 [libata]
ahci_init_one+0x6c9/0xd20 [ahci]
Ensure that we will not call kfree(host) twice, by performing the kfree()
only if the devres_open_group() call failed.
CVE-2024-41087
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference.
CVE-2024-41089
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tap: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
sent downstack. Even before the skb is transmitted, the
tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
access beyond the actual length, or confuse the underlayer with incorrect
or inconsistent header length in the skb metadata.
In the alternative path, tap_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted.
This is to drop any frame shorter than the Ethernet header size just like
how tap_get_user() does.
CVE: CVE-2024-41090
CVE-2024-41090
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
tun: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
downstack. Even before the skb is transmitted, the
tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
can be less than ETH_HLEN. Once transmitted, this could either cause
out-of-bound access beyond the actual length, or confuse the underlayer
with incorrect or inconsistent header length in the skb metadata.
In the alternative path, tun_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted for
IFF_TAP.
This is to drop any frame shorter than the Ethernet header size just like
how tun_get_user() does.
CVE: CVE-2024-41091
CVE-2024-41091
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2024-41095
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: atm: cxacru: fix endpoint checking in cxacru_bind()
Syzbot is still reporting quite an old issue [1] that occurs due to
incomplete checking of present usb endpoints. As such, wrong
endpoints types may be used at urb sumbitting stage which in turn
triggers a warning in usb_submit_urb().
Fix the issue by verifying that required endpoint types are present
for both in and out endpoints, taking into account cmd endpoint type.
Unfortunately, this patch has not been tested on real hardware.
[1] Syzbot report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
...
Call Trace:
cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:517 [inline]
really_probe+0x23c/0xcd0 drivers/base/dd.c:595
__driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
__device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
__device_attach+0x228/0x4a0 drivers/base/dd.c:965
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
device_add+0xc2f/0x2180 drivers/base/core.c:3354
usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
CVE-2024-41097
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix null pointer dereference on error
If the ata_port_alloc() call in ata_host_alloc() fails,
ata_host_release() will get called.
However, the code in ata_host_release() tries to free ata_port struct
members unconditionally, which can lead to the following:
BUG: unable to handle page fault for address: 0000000000003990
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
? __die_body.cold+0x19/0x27
? page_fault_oops+0x15a/0x2f0
? exc_page_fault+0x7e/0x180
? asm_exc_page_fault+0x26/0x30
? ata_host_release.cold+0x2f/0x6e [libata]
? ata_host_release.cold+0x2f/0x6e [libata]
release_nodes+0x35/0xb0
devres_release_group+0x113/0x140
ata_host_alloc+0xed/0x120 [libata]
ata_host_alloc_pinfo+0x14/0xa0 [libata]
ahci_init_one+0x6c9/0xd20 [ahci]
Do not access ata_port struct members unconditionally.
CVE-2024-41098
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Vim is an open source command line text editor. double-free in dialog_changed() in Vim < v9.1.0648. When abandoning a buffer, Vim may ask the user what to do with the modified buffer. If the user wants the changed buffer to be saved, Vim may create a new Untitled file, if the buffer did not have a name yet. However, when setting the buffer name to Unnamed, Vim will falsely free a pointer twice, leading to a double-free and possibly later to a heap-use-after-free, which can lead to a crash. The issue has been fixed as of Vim patch v9.1.0648.
CVE-2024-41965
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however,
the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This
only requires a new helper function to infer the register type from the
set datatype so this conditional check can be removed. Otherwise,
pointer to chain object can be leaked through the registers.
CVE-2024-42070
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix DIO failure due to insufficient transaction credits
The code in ocfs2_dio_end_io_write() estimates number of necessary
transaction credits using ocfs2_calc_extend_credits(). This however does
not take into account that the IO could be arbitrarily large and can
contain arbitrary number of extents.
Extent tree manipulations do often extend the current transaction but not
in all of the cases. For example if we have only single block extents in
the tree, ocfs2_mark_extent_written() will end up calling
ocfs2_replace_extent_rec() all the time and we will never extend the
current transaction and eventually exhaust all the transaction credits if
the IO contains many single block extents. Once that happens a
WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
this error. This was actually triggered by one of our customers on a
heavily fragmented OCFS2 filesystem.
To fix the issue make sure the transaction always has enough credits for
one extent insert before each call of ocfs2_mark_extent_written().
Heming Zhao said:
------
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA"
#0 machine_kexec at ffffffff8c069932
#1 __crash_kexec at ffffffff8c1338fa
#2 panic at ffffffff8c1d69b9
#3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
#4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
#5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
#6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
#7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
#8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
#9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
#11 dio_complete at ffffffff8c2b9fa7
#12 do_blockdev_direct_IO at ffffffff8c2bc09f
#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
#14 generic_file_direct_write at ffffffff8c1dcf14
#15 __generic_file_write_iter at ffffffff8c1dd07b
#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
#17 aio_write at ffffffff8c2cc72e
#18 kmem_cache_alloc at ffffffff8c248dde
#19 do_io_submit at ffffffff8c2ccada
#20 do_syscall_64 at ffffffff8c004984
#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba
CVE-2024-42077
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xdp: Remove WARN() from __xdp_reg_mem_model()
syzkaller reports a warning in __xdp_reg_mem_model().
The warning occurs only if __mem_id_init_hash_table() returns an error. It
returns the error in two cases:
1. memory allocation fails;
2. rhashtable_init() fails when some fields of rhashtable_params
struct are not initialized properly.
The second case cannot happen since there is a static const rhashtable_params
struct with valid fields. So, warning is only triggered when there is a
problem with memory allocation.
Thus, there is no sense in using WARN() to handle this error and it can be
safely removed.
WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
Call Trace:
xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
xdp_test_run_setup net/bpf/test_run.c:188 [inline]
bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
__sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
__do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Found by Linux Verification Center (linuxtesting.org) with syzkaller.
CVE-2024-42082
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
a potential deadlock.
This patch resolves the issue by releasing pinctrl_maps_mutex before
calling pinctrl_free(), preventing the deadlock.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
CVE-2024-42090
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/dpaa2: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config-neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
CVE-2024-42093
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86: stop playing stack games in profile_pc()
The 'profile_pc()' function is used for timer-based profiling, which
isn't really all that relevant any more to begin with, but it also ends
up making assumptions based on the stack layout that aren't necessarily
valid.
Basically, the code tries to account the time spent in spinlocks to the
caller rather than the spinlock, and while I support that as a concept,
it's not worth the code complexity or the KASAN warnings when no serious
profiling is done using timers anyway these days.
And the code really does depend on stack layout that is only true in the
simplest of cases. We've lost the comment at some point (I think when
the 32-bit and 64-bit code was unified), but it used to say:
Assume the lock function has either no stack frame or a copy
of eflags from PUSHF.
which explains why it just blindly loads a word or two straight off the
stack pointer and then takes a minimal look at the values to just check
if they might be eflags or the return pc:
Eflags always has bits 22 and up cleared unlike kernel addresses
but that basic stack layout assumption assumes that there isn't any lock
debugging etc going on that would complicate the code and cause a stack
frame.
It causes KASAN unhappiness reported for years by syzkaller [1] and
others [2].
With no real practical reason for this any more, just remove the code.
Just for historical interest, here's some background commits relating to
this code from 2006:
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
31679f38d886 ("Simplify profile_pc on x86-64")
and a code unification from 2009:
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
but the basics of this thing actually goes back to before the git tree.
CVE-2024-42096
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdh - explicitly zeroize private_key
private_key is overwritten with the key parameter passed in by the
caller (if present), or alternatively a newly generated private key.
However, it is possible that the caller provides a key (or the newly
generated key) which is shorter than the previous key. In that
scenario, some key material from the previous key would not be
overwritten. The easiest solution is to explicitly zeroize the entire
private_key array first.
Note that this patch slightly changes the behavior of this function:
previously, if the ecc_gen_privkey failed, the old private_key would
remain. Now, the private_key is always zeroized. This behavior is
consistent with the case where params.key is set and ecc_is_key_valid
fails.
CVE-2024-42098
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2024-42101
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
inet_diag: Initialize pad field in struct inet_diag_req_v2
KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
sockets uses the pad field in struct inet_diag_req_v2 for the
underlying protocol. This field corresponds to the sdiag_raw_protocol
field in struct inet_diag_req_raw.
inet_diag_get_exact_compat() converts inet_diag_req to
inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
occurs when raw_lookup() accesses the sdiag_raw_protocol field.
Fix this by initializing the pad field in
inet_diag_get_exact_compat(). Also, do the same fix in
inet_diag_dump_compat() to avoid the similar issue in the future.
[1]
BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
raw_lookup net/ipv4/raw_diag.c:49 [inline]
raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
inet_diag_cmd_exact+0x7d9/0x980
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
__sys_sendmsg net/socket.c:2668 [inline]
__do_sys_sendmsg net/socket.c:2677 [inline]
__se_sys_sendmsg net/socket.c:2675 [inline]
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was stored to memory at:
raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
inet_diag_cmd_exact+0x7d9/0x980
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
__sys_sendmsg net/socket.c:2668 [inline]
__do_sys_sendmsg net/socket.c:2677 [inline]
__se_sys_sendmsg net/socket.c:2675 [inline]
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable req.i created at:
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
CVE-2024-42106
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()
The following is emitted when using idxd (DSA) dmanegine as the data
mover for ntb_transport that ntb_netdev uses.
[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526
[74412.556784] caller is netif_rx_internal+0x42/0x130
[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5
[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024
[74412.581699] Call Trace:
[74412.584514] <TASK>
[74412.586933] dump_stack_lvl+0x55/0x70
[74412.591129] check_preemption_disabled+0xc8/0xf0
[74412.596374] netif_rx_internal+0x42/0x130
[74412.600957] __netif_rx+0x20/0xd0
[74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev]
[74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport]
[74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport]
[74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd]
[74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd]
[74412.634046] irq_thread_fn+0x21/0x60
[74412.638134] ? irq_thread+0xa8/0x290
[74412.642218] irq_thread+0x1a0/0x290
[74412.646212] ? __pfx_irq_thread_fn+0x10/0x10
[74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10
[74412.656117] ? __pfx_irq_thread+0x10/0x10
[74412.660686] kthread+0x100/0x130
[74412.664384] ? __pfx_kthread+0x10/0x10
[74412.668639] ret_from_fork+0x31/0x50
[74412.672716] ? __pfx_kthread+0x10/0x10
[74412.676978] ret_from_fork_asm+0x1a/0x30
[74412.681457] </TASK>
The cause is due to the idxd driver interrupt completion handler uses
threaded interrupt and the threaded handler is not hard or soft interrupt
context. However __netif_rx() can only be called from interrupt context.
Change the call to netif_rx() in order to allow completion via normal
context for dmaengine drivers that utilize threaded irq handling.
While the following commit changed from netif_rx() to __netif_rx(),
baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),
the change should've been a noop instead. However, the code precedes this
fix should've been using netif_rx_ni() or netif_rx_any_context().
CVE-2024-42110
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline]
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __list_del include/linux/list.h:195 [inline]
pc : __list_del_entry include/linux/list.h:218 [inline]
pc : list_move_tail include/linux/list.h:310 [inline]
pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
lr : __list_del_entry include/linux/list.h:218 [inline]
lr : list_move_tail include/linux/list.h:310 [inline]
lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
__list_del include/linux/list.h:195 [inline]
__list_del_entry include/linux/list.h:218 [inline]
list_move_tail include/linux/list.h:310 [inline]
fq_tin_dequeue include/net/fq_impl.h:112 [inline]
ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
wake_tx_push_queue net/mac80211/util.c:294 [inline]
ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
__ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
__dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
neigh_output include/net/neighbour.h:542 [inline]
ip6_fini
---truncated---
CVE-2024-42114
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip finding free audio for unknown engine_id
[WHY]
ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it
also means it is uninitialized and does not need free audio.
[HOW]
Skip and return NULL.
This fixes 2 OVERRUN issues reported by Coverity.
CVE-2024-42119
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check pipe offset before setting vblank
pipe_ctx has a size of MAX_PIPES so checking its index before accessing
the array.
This fixes an OVERRUN issue reported by Coverity.
CVE-2024-42120
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Make qedf_execute_tmf() non-preemptible
Stop calling smp_processor_id() from preemptible code in
qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.
[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646
[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]
CVE-2024-42124
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty
limits in PAGE_SIZE units fit into 32-bit (so that various multiplications
fit into 64-bits). If limits end up being larger, we will hit overflows,
possible divisions by 0 etc. Fix these problems by never allowing so
large dirty limits as they have dubious practical value anyway. For
dirty_bytes / dirty_background_bytes interfaces we can just refuse to set
so large limits. For dirty_ratio / dirty_background_ratio it isn't so
simple as the dirty limit is computed from the amount of available memory
which can change due to memory hotplug etc. So when converting dirty
limits from ratios to numbers of pages, we just don't allow the result to
exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator
sets dirty limits to >16 TB.
CVE-2024-42131
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Implement a limit on UMAD receive List
The existing behavior of ib_umad, which maintains received MAD
packets in an unbounded list, poses a risk of uncontrolled growth.
As user-space applications extract packets from this list, the rate
of extraction may not match the rate of incoming packets, leading
to potential list overflow.
To address this, we introduce a limit to the size of the list. After
considering typical scenarios, such as OpenSM processing, which can
handle approximately 100k packets per second, and the 1-second retry
timeout for most packets, we set the list size limit to 200k. Packets
received beyond this limit are dropped, assuming they are likely timed
out by the time they are handled by user-space.
Notably, packets queued on the receive list due to reasons like
timed-out sends are preserved even when the list is full.
CVE-2024-42145
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
Fix UBSAN warnings that occur when using a system with 32 physical
cpu cores or more, or when the user defines a number of Ethernet
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
module parameter.
Currently there is a read/write out of bounds that occurs on the array
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
Looking at the definition of the "struct stats_query_entry query" array:
struct stats_query_entry query[FP_SB_MAX_E1x+
BNX2X_FIRST_QUEUE_QUERY_IDX];
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
meaning the array has a total size of 19.
Since accesses to "struct stats_query_entry query" are offset-ted by
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
is reserved for FCOE and thus the number of Ethernet queues should be set
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
it is not.
This is also described in a comment in the source code in
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
for this patch
/*
* The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
* control by the number of fast-path status blocks supported by the
* device (HW/FW). Each fast-path status block (FP-SB) aka non-default
* status block represents an independent interrupts context that can
* serve a regular L2 networking queue. However special L2 queues such
* as the FCoE queue do not require a FP-SB and other components like
* the CNIC may consume FP-SB reducing the number of possible L2 queues
*
* If the maximum number of FP-SB available is X then:
* a. If CNIC is supported it consumes 1 FP-SB thus the max number of
* regular L2 queues is Y=X-1
* b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
* c. If the FCoE L2 queue is supported the actual number of L2 queues
* is Y+1
* d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
* slow-path interrupts) or Y+2 if CNIC is supported (one additional
* FP interrupt context for the CNIC).
* e. The number of HW context (CID count) is always X or X+1 if FCoE
* L2 queue is supported. The cid for the FCoE L2 queue is always X.
*/
However this driver also supports NICs that use the E2 controller which can
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
Looking at the commits when the E2 support was added, it was originally
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
was later updated to take full advantage of the E2 instead of having it be
limited to the capabilities of the E1x. But as far as we can tell, the
array "stats_query_entry query" was still limited to using the FP-SB
available to the E1x cards as part of an oversignt when the driver was
updated to take full advantage of the E2, and now with the driver being
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
warnings seen in the stack traces below.
This patch increases the size of the "stats_query_entry query" array by
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
both types of NICs.
Stack traces:
UBSAN: array-index-out-of-bounds in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
index 20 is out of range for type 'stats_query_entry [19]'
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
#202405052133
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
---truncated---
CVE-2024-42148
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: validate source addr length
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
is at least 4 bytes long, and the policy doesn't have an entry
for this attribute at all (neither does it for IPv6 but v6 is
manually validated).
CVE-2024-42154
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of protected- and secure-keys
Although the clear-key of neither protected- nor secure-keys is
accessible, this key material should only be visible to the calling
process. So wipe all copies of protected- or secure-keys from stack,
even in case of an error.
CVE-2024-42155
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe sensitive data on failure
Wipe sensitive data from stack also if the copy_to_user() fails.
CVE-2024-42157
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
Replace memzero_explicit() and kfree() with kfree_sensitive() to fix
warnings reported by Coccinelle:
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)
CVE-2024-42158
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gve: Account for stopped queues when reading NIC stats
We now account for the fact that the NIC might send us stats for a
subset of queues. Without this change, gve_get_ethtool_stats might make
an invalid access on the priv->stats_report->stats array.
CVE-2024-42162
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer
when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.
CVE-2024-42223
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Correct check for empty list
Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO
busses") mv88e6xxx_default_mdio_bus() has checked that the
return value of list_first_entry() is non-NULL.
This appears to be intended to guard against the list chip->mdios being
empty. However, it is not the correct check as the implementation of
list_first_entry is not designed to return NULL for empty lists.
Instead, use list_first_entry_or_null() which does return NULL if the
list is empty.
Flagged by Smatch.
Compile tested only.
CVE-2024-42224
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-42226
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc
Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.
V2: To really improve the handling we would actually
need to have a separate value of 0xffffffff.(Christian)
CVE-2024-42228
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: aead,cipher - zeroize key buffer after use
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
cryptographic information should be zeroized once they are no longer
needed. Accomplish this by using kfree_sensitive for buffers that
previously held the private key.
CVE-2024-42229
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to
races with mon_fault() and possibly also finish_hunting(). Both of
these can requeue the delayed work which wouldn't be canceled by any of
the following code in case that happens after cancel_delayed_work_sync()
runs -- __close_session() doesn't mess with the delayed work in order
to avoid interfering with the hunting interval logic. This part was
missed in commit b5d91704f53e ("libceph: behave in mon_fault() if
cur_mon < 0") and use-after-free can still ensue on monc and objects
that hang off of it, with monc->auth and monc->monmap being
particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session
in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how
it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed
CVE-2024-42232
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
`if (str[0 - 1] == '\n') followed closely by an OOB write in the form
`str[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long.
Let's supply an additional check for invalid strings that are too short.
CVE-2024-42236
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/bhi: Avoid warning in #DB handler due to BHI mitigation
When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set
then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the
clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler
(exc_debug_kernel()) to issue a warning because single-step is used outside the
entry_SYSENTER_compat() function.
To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY
after making sure the TF flag is cleared.
The problem can be reproduced with the following sequence:
$ cat sysenter_step.c
int main()
{ asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }
$ gcc -o sysenter_step sysenter_step.c
$ ./sysenter_step
Segmentation fault (core dumped)
The program is expected to crash, and the #DB handler will issue a warning.
Kernel log:
WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160
...
RIP: 0010:exc_debug_kernel+0xd2/0x160
...
Call Trace:
<#DB>
? show_regs+0x68/0x80
? __warn+0x8c/0x140
? exc_debug_kernel+0xd2/0x160
? report_bug+0x175/0x1a0
? handle_bug+0x44/0x90
? exc_invalid_op+0x1c/0x70
? asm_exc_invalid_op+0x1f/0x30
? exc_debug_kernel+0xd2/0x160
exc_debug+0x43/0x50
asm_exc_debug+0x1e/0x40
RIP: 0010:clear_bhb_loop+0x0/0xb0
...
</#DB>
<TASK>
? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d
</TASK>
[ bp: Massage commit message. ]
CVE-2024-42240
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mos7840: fix crash on resume
Since commit c49cfa917025 ("USB: serial: use generic method if no
alternative is provided in usb serial layer"), USB serial core calls the
generic resume implementation when the driver has not provided one.
This can trigger a crash on resume with mos7840 since support for
multiple read URBs was added back in 2011. Specifically, both port read
URBs are now submitted on resume for open ports, but the context pointer
of the second URB is left set to the core rather than mos7840 port
structure.
Fix this by implementing dedicated suspend and resume functions for
mos7840.
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
[ johan: analyse crash and rewrite commit message; set busy flag on
resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
CVE-2024-42244
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
When using a BPF program on kernel_connect(), the call can return -EPERM. This
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
the kernel to potentially freeze up.
Neil suggested:
This will propagate -EPERM up into other layers which might not be ready
to handle it. It might be safer to map EPERM to an error we would be more
likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
ECONNREFUSED as error seems reasonable. For programs setting a different error
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean"), thus given that it is better to simply remap for
consistent behavior. UDP does handle EPERM in xs_udp_send_request().
CVE-2024-42246
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
Ensure that `i2c_lock' is held when setting interrupt latch and mask in
pca953x_irq_bus_sync_unlock() in order to avoid races.
The other (non-probe) call site pca953x_gpio_set_multiple() ensures the
lock is held before calling pca953x_write_regs().
The problem occurred when a request raced against irq_bus_sync_unlock()
approximately once per thousand reboots on an i.MX8MP based system.
* Normal case
0-0022: write register AI|3a {03,02,00,00,01} Input latch P0
0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
0-0022: write register AI|08 {ff,00,00,00,00} Output P3
0-0022: write register AI|12 {fc,00,00,00,00} Config P3
* Race case
0-0022: write register AI|08 {ff,00,00,00,00} Output P3
0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***
0-0022: write register AI|12 {fc,00,00,00,00} Config P3
0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
CVE-2024-42253
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
Calculating the size of the mapped area as the lesser value
between the requested size and the actual size does not consider
the partial mapping offset. This can cause page fault access.
Fix the calculation of the starting and ending addresses, the
total size is now deduced from the difference between the end and
start addresses.
Additionally, the calculations have been rewritten in a clearer
and more understandable form.
[Joonas: Add Requires: tag]
Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")
(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
CVE-2024-42259
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
protect the fetch of ->fd[fd] in do_dup2() from mispredictions
both callers have verified that fd is not greater than ->max_fds;
however, misprediction might end up with
tofree = fdt->fd[fd];
being speculatively executed. That's wrong for the same reasons
why it's wrong in close_fd()/file_close_fd_locked(); the same
solution applies - array_index_nospec(fd, fdt->max_fds) could differ
from fd only in case of speculative execution on mispredicted path.
CVE-2024-42265
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix use after free in iucv_sock_close()
iucv_sever_path() is called from process context and from bh context.
iucv->path is used as indicator whether somebody else is taking care of
severing the path (or it is already removed / never existed).
This needs to be done with atomic compare and swap, otherwise there is a
small window where iucv_sock_close() will try to work with a path that has
already been severed and freed by iucv_callback_connrej() called by
iucv_tasklet_fn().
Example:
[452744.123844] Call Trace:
[452744.123845] ([<0000001e87f03880>] 0x1e87f03880)
[452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138
[452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv]
[452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv]
[452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv]
[452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8
[452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48
[452744.124820] [<00000000d5421642>] __fput+0xba/0x268
[452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0
[452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90
[452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8
[452744.125319] Last Breaking-Event-Address:
[452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138
[452744.125324]
[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt
Note that bh_lock_sock() is not serializing the tasklet context against
process context, because the check for sock_owned_by_user() and
corresponding handling is missing.
Ideas for a future clean-up patch:
A) Correct usage of bh_lock_sock() in tasklet context, as described in
Re-enqueue, if needed. This may require adding return values to the
tasklet functions and thus changes to all users of iucv.
B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.
CVE-2024-42271
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
mISDN: Fix a use after free in hfcmulti_tx()
Don't dereference *sp after calling dev_kfree_skb(*sp).
CVE-2024-42280
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a segment issue when downgrading gso_size
Linearize the skb when downgrading gso_size because it may trigger a
BUG_ON() later when the skb is segmented as described in [1,2].
CVE-2024-42281
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: Return non-zero value from tipc_udp_addr2str() on error
tipc_udp_addr2str() should return non-zero value if the UDP media
address is invalid. Otherwise, a buffer overflow access can occur in
tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP
media address.
CVE-2024-42284
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix a use-after-free related to destroying CM IDs
iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with
an existing struct iw_cm_id (cm_id) as follows:
conn_id->cm_id.iw = cm_id;
cm_id->context = conn_id;
cm_id->cm_handler = cma_iw_handler;
rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make
sure that cm_work_handler() does not trigger a use-after-free by only
freeing of the struct rdma_id_private after all pending work has finished.
CVE-2024-42285
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: validate nvme_local_port correctly
The driver load failed with error message,
qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef
and with a kernel crash,
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
Call Trace:
qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
qla_register_fcport_fn+0x54/0xc0 [qla2xxx]
Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()
fails and correctly validate nvme_local_port.
CVE-2024-42286
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Complete command early within lock
A crash was observed while performing NPIV and FW reset,
BUG: kernel NULL pointer dereference, address: 000000000000001c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 1 PREEMPT_RT SMP NOPTI
RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0
RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034
R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000
R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000
FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? __die_body+0x1a/0x60
? page_fault_oops+0x16f/0x4a0
? do_user_addr_fault+0x174/0x7f0
? exc_page_fault+0x69/0x1a0
? asm_exc_page_fault+0x22/0x30
? dma_direct_unmap_sg+0x51/0x1e0
? preempt_count_sub+0x96/0xe0
qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]
qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]
__qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]
The command completion was done early while aborting the commands in driver
unload path but outside lock to avoid the WARN_ON condition of performing
dma_free_attr within the lock. However this caused race condition while
command completion via multiple paths causing system crash.
Hence complete the command early in unload path but within the lock to
avoid race condition.
CVE-2024-42287
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix for possible memory corruption
Init Control Block is dereferenced incorrectly. Correctly dereference ICB
CVE-2024-42288
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: During vport delete send async logout explicitly
During vport delete, it is observed that during unload we hit a crash
because of stale entries in outstanding command array. For all these stale
I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but
I/Os could not complete while vport delete is in process of deleting.
BUG: kernel NULL pointer dereference, address: 000000000000001c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
Workqueue: qla2xxx_wq qla_do_work [qla2xxx]
RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001
RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0
RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8
R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000
R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0
Call Trace:
<TASK>
qla2xxx_qpair_sp_free_dma+0x417/0x4e0
? qla2xxx_qpair_sp_compl+0x10d/0x1a0
? qla2x00_status_entry+0x768/0x2830
? newidle_balance+0x2f0/0x430
? dequeue_entity+0x100/0x3c0
? qla24xx_process_response_queue+0x6a1/0x19e0
? __schedule+0x2d5/0x1140
? qla_do_work+0x47/0x60
? process_one_work+0x267/0x440
? process_one_work+0x440/0x440
? worker_thread+0x2d/0x3d0
? process_one_work+0x440/0x440
? kthread+0x156/0x180
? set_kthread_struct+0x50/0x50
? ret_from_fork+0x22/0x30
</TASK>
Send out async logout explicitly for all the ports during vport delete.
CVE-2024-42289
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dev/parport: fix the array out-of-bounds risk
Fixed array out-of-bounds issues caused by sprintf
by replacing it with snprintf for safer data copying,
ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]
CVE-2024-42301
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: check dot and dotdot of dx_root before making dir indexed
Syzbot reports a issue as follows:
============================================
BUG: unable to handle page fault for address: ffffed11022e24fe
PGD 23ffee067 P4D 23ffee067 PUD 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0
Call Trace:
<TASK>
make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341
ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451
ext4_rename fs/ext4/namei.c:3936 [inline]
ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214
[...]
============================================
The immediate cause of this problem is that there is only one valid dentry
for the block to be split during do_split, so split==0 results in out of
bounds accesses to the map triggering the issue.
do_split
unsigned split
dx_make_map
count = 1
split = count/2 = 0;
continued = hash2 == map[split - 1].hash;
---> map[4294967295]
The maximum length of a filename is 255 and the minimum block size is 1024,
so it is always guaranteed that the number of entries is greater than or
equal to 2 when do_split() is called.
But syzbot's crafted image has no dot and dotdot in dir, and the dentry
distribution in dirblock is as follows:
bus dentry1 hole dentry2 free
|xx--|xx-------------|...............|xx-------------|...............|
0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024
So when renaming dentry1 increases its name_len length by 1, neither hole
nor free is sufficient to hold the new dentry, and make_indexed_dir() is
called.
In make_indexed_dir() it is assumed that the first two entries of the
dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root
because they are treated as dot and dotdot, and only dentry2 is moved
to the new leaf block. That's why count is equal to 1.
Therefore add the ext4_check_dx_root() helper function to add more sanity
checks to dot and dotdot before starting the conversion to avoid the above
issue.
CVE-2024-42305
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
udf: Avoid using corrupted block bitmap buffer
When the filesystem block bitmap is corrupted, we detect the corruption
while loading the bitmap and fail the allocation with error. However the
next allocation from the same bitmap will notice the bitmap buffer is
already loaded and tries to allocate from the bitmap with mixed results
(depending on the exact nature of the bitmap corruption). Fix the
problem by using BH_verified bit to indicate whether the bitmap is valid
or not.
CVE-2024-42306
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes
In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2024-42309
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2024-42310
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sysctl: always initialize i_uid/i_gid
Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.
Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when
set_ownership() was not implemented. It also missed adjusting
net_ctl_set_ownership() to use the same default values in case the
computation of a better value failed.
CVE-2024-42312
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvs: properly dereference pe in ip_vs_add_service
Use pe directly to resolve sparse warning:
net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression
CVE-2024-42322
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.
CVE-2024-43374
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.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-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.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-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kvm: s390: Reject memory region operations for ucontrol VMs
This change rejects the KVM_SET_USER_MEMORY_REGION and
KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.
This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and
would thus result in a null pointer dereference further in.
Memory management needs to be performed in userspace and using the
ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.
Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION
and KVM_SET_USER_MEMORY_REGION2.
[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]
CVE-2024-43819
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Handle invalid decoder vsi
Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi
is valid for future use.
CVE-2024-43831
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently
'name' size is 16, but the first '%s' specifier may already need at
least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require:
* 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8
* 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX
is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.
CVE-2024-43839
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Prevent UAF in proc_cpuset_show()
An UAF can happen when /proc/cpuset is read as reported in [1].
This can be reproduced by the following methods:
1.add an mdelay(1000) before acquiring the cgroup_lock In the
cgroup_path_ns function.
2.$cat /proc/<pid>/cpuset repeatly.
3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/
$umount /sys/fs/cgroup/cpuset/ repeatly.
The race that cause this bug can be shown as below:
(umount) | (cat /proc/<pid>/cpuset)
css_release | proc_cpuset_show
css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id);
css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...);
cgroup_destroy_root | mutex_lock(&cgroup_mutex);
rebind_subsystems |
cgroup_free_root |
| // cgrp was freed, UAF
| cgroup_path_ns_locked(cgrp,..);
When the cpuset is initialized, the root node top_cpuset.css.cgrp
will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will
allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated
&cgroup_root.cgrp. When the umount operation is executed,
top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.
The problem is that when rebinding to cgrp_dfl_root, there are cases
where the cgroup_root allocated by setting up the root for cgroup v1
is cached. This could lead to a Use-After-Free (UAF) if it is
subsequently freed. The descendant cgroups of cgroup v1 can only be
freed after the css is released. However, the css of the root will never
be released, yet the cgroup_root should be freed when it is unmounted.
This means that obtaining a reference to the css of the root does
not guarantee that css.cgrp->root will not be freed.
Fix this problem by using rcu_read_lock in proc_cpuset_show().
As cgroup_root is kfree_rcu after commit d23b5c577715
("cgroup: Make operations on the cgroup root_list RCU safe"),
css->cgroup won't be freed during the critical section.
To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to
replace task_get_css with task_css.
[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd
CVE-2024-43853
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads
to random kernel memory being written media. For PI metadata this is
limited to the app tag that isn't used by kernel generated metadata,
but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes.
CVE-2024-43854
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dma: fix call order in dmam_free_coherent
dmam_free_coherent() frees a DMA allocation, which makes the
freed vaddr available for reuse, then calls devres_destroy()
to remove and free the data structure used to track the DMA
allocation. Between the two calls, it is possible for a
concurrent task to make an allocation with the same vaddr
and add it to the devres list.
If this happens, there will be two entries in the devres list
with the same vaddr and devres_destroy() can free the wrong
entry, triggering the WARN_ON() in dmam_match.
Fix by destroying the devres entry before freeing the DMA
allocation.
kokonut //net/encryption
http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03
CVE-2024-43856
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: fix memory leak for not ip packets
Free the unused skb when not ip packets arrive.
CVE-2024-43861
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix a deadlock in dma buf fence polling
Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.
vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.
dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.
Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.
CVE-2024-43863
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Always drain health in shutdown callback
There is no point in recovery during device shutdown. if health
work started need to wait for it to avoid races and NULL pointer
access.
Hence, drain health WQ on shutdown callback.
CVE-2024-43866
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu()
to free memory allocated by devm_alloc_percpu(), fixed by using
devres_release() instead of devres_destroy() within devm_free_percpu().
CVE-2024-43871
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix soft lockup under heavy CEQE load
CEQEs are handled in interrupt handler currently. This may cause the
CPU core staying in interrupt context too long and lead to soft lockup
under heavy load.
Handle CEQEs in BH workqueue and set an upper limit for the number of
CEQE handled by a single call of work handler.
CVE-2024-43872
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in
cfg80211_calculate_bitrate_he(), leading to below warning:
kernel: invalid HE MCS: bw:6, ru:6
kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]
Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.
CVE-2024-43879
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
exec: Fix ToCToU between perm check and set-uid/gid usage
When opening a file for exec via do_filp_open(), permission checking is
done against the file's metadata at that moment, and on success, a file
pointer is passed back. Much later in the execve() code path, the file
metadata (specifically mode, uid, and gid) is used to determine if/how
to set the uid and gid. However, those values may have changed since the
permissions check, meaning the execution may gain unintended privileges.
For example, if a file could change permissions from executable and not
set-id:
---------x 1 root root 16048 Aug 7 13:16 target
to set-id and non-executable:
---S------ 1 root root 16048 Aug 7 13:16 target
it is possible to gain root privileges when execution should have been
disallowed.
While this race condition is rare in real-world scenarios, it has been
observed (and proven exploitable) when package managers are updating
the setuid bits of installed programs. Such files start with being
world-executable but then are adjusted to be group-exec with a set-uid
bit. For example, "chmod o-x,u+s target" makes "target" executable only
by uid "root" and gid "cdrom", while also becoming setuid-root:
-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target
becomes:
-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target
But racing the chmod means users without group "cdrom" membership can
get the permission to execute "target" just before the chmod, and when
the chmod finishes, the exec reaches brpm_fill_uid(), and performs the
setuid to root, violating the expressed authorization of "only cdrom
group members can setuid to root".
Re-check that we still have execute permissions in case the metadata
has changed. It would be better to keep a copy from the perm-check time,
but until we can do that refactoring, the least-bad option is to do a
full inode_permission() call (under inode lock). It is understood that
this is safe against dead-locks, but hardly optimal.
CVE-2024-43882
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers
to references that can still be used. Make sure that does not happen.
This strictly speaking closes ZDI-CAN-22273, though there may be
similar races in the driver.
CVE-2024-43883
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Add error handling to pair_device()
hci_conn_params_add() never checks for a NULL value and could lead to a NULL
pointer dereference causing a crash.
Fixed by adding error handling in the function.
CVE-2024-43884
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix overflow in get_free_elt()
"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (`max_elts`) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing "tracing_map->max_size" elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
`__tracing_map_insert()`, it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.
Fix this by preventing any further increments to "tracing_map->next_elt"
once it reaches "tracing_map->max_elt".
CVE-2024-43890
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
memcg: protect concurrent access to mem_cgroup_idr
Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after
many small jobs") decoupled the memcg IDs from the CSS ID space to fix the
cgroup creation failures. It introduced IDR to maintain the memcg ID
space. The IDR depends on external synchronization mechanisms for
modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace()
happen within css callback and thus are protected through cgroup_mutex
from concurrent modifications. However idr_remove() for mem_cgroup_idr
was not protected against concurrency and can be run concurrently for
different memcgs when they hit their refcnt to zero. Fix that.
We have been seeing list_lru based kernel crashes at a low frequency in
our fleet for a long time. These crashes were in different part of
list_lru code including list_lru_add(), list_lru_del() and reparenting
code. Upon further inspection, it looked like for a given object (dentry
and inode), the super_block's list_lru didn't have list_lru_one for the
memcg of that object. The initial suspicions were either the object is
not allocated through kmem_cache_alloc_lru() or somehow
memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
returned success. No evidence were found for these cases.
Looking more deeply, we started seeing situations where valid memcg's id
is not present in mem_cgroup_idr and in some cases multiple valid memcgs
have same id and mem_cgroup_idr is pointing to one of them. So, the most
reasonable explanation is that these situations can happen due to race
between multiple idr_remove() calls or race between
idr_alloc()/idr_replace() and idr_remove(). These races are causing
multiple memcgs to acquire the same ID and then offlining of one of them
would cleanup list_lrus on the system for all of them. Later access from
other memcgs to the list_lru cause crashes due to missing list_lru_one.
CVE-2024-43892
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: core: check uartclk for zero to avoid divide by zero
Calling ioctl TIOCSSERIAL with an invalid baud_base can
result in uartclk being zero, which will result in a
divide by zero error in uart_get_divisor(). The check for
uartclk being zero in uart_set_info() needs to be done
before other settings are made as subsequent calls to
ioctl TIOCSSERIAL for the same port would be impacted if
the uartclk check was done where uartclk gets set.
Oops: divide error: 0000 PREEMPT SMP KASAN PTI
RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)
Call Trace:
<TASK>
serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576
drivers/tty/serial/8250/8250_port.c:2589)
serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502
drivers/tty/serial/8250/8250_port.c:2741)
serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)
uart_change_line_settings (./include/linux/spinlock.h:376
./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)
uart_port_startup (drivers/tty/serial/serial_core.c:342)
uart_startup (drivers/tty/serial/serial_core.c:368)
uart_set_info (drivers/tty/serial/serial_core.c:1034)
uart_set_info_user (drivers/tty/serial/serial_core.c:1059)
tty_set_serial (drivers/tty/tty_io.c:2637)
tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)
__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907
fs/ioctl.c:893 fs/ioctl.c:893)
do_syscall_64 (arch/x86/entry/common.c:52
(discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Rule: add
CVE-2024-43893
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-43898
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: xc2028: avoid use-after-free in load_firmware_cb()
syzkaller reported use-after-free in load_firmware_cb() [1].
The reason is because the module allocated a struct tuner in tuner_probe(),
and then the module initialization failed, the struct tuner was released.
A worker which created during module initialization accesses this struct
tuner later, it caused use-after-free.
The process is as follows:
task-6504 worker_thread
tuner_probe <= alloc dvb_frontend [2]
...
request_firmware_nowait <= create a worker
...
tuner_remove <= free dvb_frontend
...
request_firmware_work_func <= the firmware is ready
load_firmware_cb <= but now the dvb_frontend has been freed
To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is
null, report a warning and just return.
[1]:
==================================================================
BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504
Call trace:
load_firmware_cb+0x1310/0x17a0
request_firmware_work_func+0x128/0x220
process_one_work+0x770/0x1824
worker_thread+0x488/0xea0
kthread+0x300/0x430
ret_from_fork+0x10/0x20
Allocated by task 6504:
kzalloc
tuner_probe+0xb0/0x1430
i2c_device_probe+0x92c/0xaf0
really_probe+0x678/0xcd0
driver_probe_device+0x280/0x370
__device_attach_driver+0x220/0x330
bus_for_each_drv+0x134/0x1c0
__device_attach+0x1f4/0x410
device_initial_probe+0x20/0x30
bus_probe_device+0x184/0x200
device_add+0x924/0x12c0
device_register+0x24/0x30
i2c_new_device+0x4e0/0xc44
v4l2_i2c_new_subdev_board+0xbc/0x290
v4l2_i2c_new_subdev+0xc8/0x104
em28xx_v4l2_init+0x1dd0/0x3770
Freed by task 6504:
kfree+0x238/0x4e4
tuner_remove+0x144/0x1c0
i2c_device_remove+0xc8/0x290
__device_release_driver+0x314/0x5fc
device_release_driver+0x30/0x44
bus_remove_device+0x244/0x490
device_del+0x350/0x900
device_unregister+0x28/0xd0
i2c_unregister_device+0x174/0x1d0
v4l2_device_unregister+0x224/0x380
em28xx_v4l2_init+0x1d90/0x3770
The buggy address belongs to the object at ffff8000d7ca2000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 776 bytes inside of
2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
The buggy address belongs to the page:
page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
flags: 0x7ff800000000100(slab)
raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
[2]
Actually, it is allocated for struct tuner, and dvb_frontend is inside.
CVE-2024-43900
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checker before passing variables
Checks null pointer before passing variables to functions.
This fixes 3 NULL_RETURNS issues reported by Coverity.
CVE-2024-43902
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
Check return value and conduct null pointer handling to avoid null pointer dereference.
CVE-2024-43905
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules
Check the pointer value to fix potential null pointer
dereference
CVE-2024-43907
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: disallow setting special AP channel widths
Setting the AP channel width is meant for use with the normal
20/40/... MHz channel width progression, and switching around
in S1G or narrow channels isn't supported. Disallow that.
CVE-2024-43912
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid BUG_ON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:
kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
<TASK>
raid5_sync_request+0x43d/0x550
md_do_sync+0xb7a/0x2110
md_thread+0x294/0x2b0
kthread+0x147/0x1c0
ret_from_fork+0x59/0x70
ret_from_fork_asm+0x1a/0x30
</TASK>
Root cause is that --revert-reshape update the raid_disks from 5 to 4,
while reshape position is still set, and after reassembling the array,
reshape position will be read from super block, then during reshape the
checking of 'writepos' that is caculated by old reshape position will
fail.
Fix this panic the easy way first, by converting the BUG_ON() to
WARN_ON(), and stop the reshape if checkings fail.
Noted that mdadm must fix --revert-shape as well, and probably md/raid
should enhance metadata validation as well, however this means
reassemble will fail and there must be user tools to fix the wrong
metadata.
CVE-2024-43914
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gpio: prevent potential speculation leaks in gpio_device_get_desc()
Userspace may trigger a speculative read of an address outside the gpio
descriptor array.
Users can do that by calling gpio_ioctl() with an offset out of range.
Offset is copied from user and then used as an array index to get
the gpio descriptor without sanitization in gpio_device_get_desc().
This change ensures that the offset is sanitized by using
array_index_nospec() to mitigate any possibility of speculative
information leaks.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
CVE-2024-44931
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
kcm: Serialise kcm_sendmsg() for the same socket.
syzkaller reported UAF in kcm_release(). [0]
The scenario is
1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
2. Thread A resumes building skb from kcm->seq_skb but is blocked
by sk_stream_wait_memory()
3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb
and puts the skb to the write queue
4. Thread A faces an error and finally frees skb that is already in the
write queue
5. kcm_release() does double-free the skb in the write queue
When a thread is building a MSG_MORE skb, another thread must not touch it.
Let's add a per-sk mutex and serialise kcm_sendmsg().
[0]:
BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]
BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]
BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167
CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call trace:
dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x178/0x518 mm/kasan/report.c:488
kasan_report+0xd8/0x138 mm/kasan/report.c:601
__asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
__skb_unlink include/linux/skbuff.h:2366 [inline]
__skb_dequeue include/linux/skbuff.h:2385 [inline]
__skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
__skb_queue_purge include/linux/skbuff.h:3181 [inline]
kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
__sock_release net/socket.c:659 [inline]
sock_close+0xa4/0x1e8 net/socket.c:1421
__fput+0x30c/0x738 fs/file_table.c:376
____fput+0x20/0x30 fs/file_table.c:404
task_work_run+0x230/0x2e0 kernel/task_work.c:180
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0x618/0x1f64 kernel/exit.c:871
do_group_exit+0x194/0x22c kernel/exit.c:1020
get_signal+0x1500/0x15ec kernel/signal.c:2893
do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249
do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148
exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Allocated by task 6166:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x40/0x78 mm/kasan/common.c:68
kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626
unpoison_slab_object mm/kasan/common.c:314 [inline]
__kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3813 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903
__alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641
alloc_skb include/linux/skbuff.h:1296 [inline]
kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
sock_sendmsg+0x220/0x2c0 net/socket.c:768
splice_to_socket+0x7cc/0xd58 fs/splice.c:889
do_splice_from fs/splice.c:941 [inline]
direct_splice_actor+0xec/0x1d8 fs/splice.c:1164
splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108
do_splice_direct_actor
---truncated---
CVE-2024-44946
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
fuse: Initialize beyond-EOF page contents before setting uptodate
fuse_notify_store(), unlike fuse_do_readpage(), does not enable page
zeroing (because it can be used to change partial page contents).
So fuse_notify_store() must be more careful to fully initialize page
contents (including parts of the page that are beyond end-of-file)
before marking the page uptodate.
The current code can leave beyond-EOF page contents uninitialized, which
makes these uninitialized page contents visible to userspace via mmap().
This is an information leak, but only affects systems which do not
enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the
corresponding kernel command line parameter).
CVE-2024-44947
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/mtrr: Check if fixed MTRRs exist before saving them
MTRRs have an obsolete fixed variant for fine grained caching control
of the 640K-1MB region that uses separate MSRs. This fixed variant has
a separate capability bit in the MTRR capability MSR.
So far all x86 CPUs which support MTRR have this separate bit set, so it
went unnoticed that mtrr_save_state() does not check the capability bit
before accessing the fixed MTRR MSRs.
Though on a CPU that does not support the fixed MTRR capability this
results in a #GP. The #GP itself is harmless because the RDMSR fault is
handled gracefully, but results in a WARN_ON().
Add the missing capability check to prevent this.
CVE-2024-44948
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: fix invalid FIFO access with special register set
When enabling access to the special register set, Receiver time-out and
RHR interrupts can happen. In this case, the IRQ handler will try to read
from the FIFO thru the RHR register at address 0x00, but address 0x00 is
mapped to DLL register, resulting in erroneous FIFO reading.
Call graph example:
sc16is7xx_startup(): entry
sc16is7xx_ms_proc(): entry
sc16is7xx_set_termios(): entry
sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set
sc16is7xx_port_irq() entry --> IIR is 0x0C
sc16is7xx_handle_rx() entry
sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is
mapped to DLL (LCR=LCR_CONF_MODE_A)
sc16is7xx_set_baud(): exit --> Restore access to general register set
Fix the problem by claiming the efr_lock mutex when accessing the Special
register set.
CVE-2024-44950
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-44952
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: line6: Fix racy access to midibuf
There can be concurrent accesses to line6 midibuf from both the URB
completion callback and the rawmidi API access. This could be a cause
of KMSAN warning triggered by syzkaller below (so put as reported-by
here).
This patch protects the midibuf call of the former code path with a
spinlock for avoiding the possible races.
CVE-2024-44954
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sched/smt: Fix unbalance sched_smt_present dec/inc
I got the following warn report while doing stress test:
jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0
Call Trace:
<TASK>
__static_key_slow_dec_cpuslocked+0x16/0x70
sched_cpu_deactivate+0x26e/0x2a0
cpuhp_invoke_callback+0x3ad/0x10d0
cpuhp_thread_fun+0x3f5/0x680
smpboot_thread_fn+0x56d/0x8d0
kthread+0x309/0x400
ret_from_fork+0x41/0x70
ret_from_fork_asm+0x1b/0x30
</TASK>
Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),
the cpu offline failed, but sched_smt_present is decremented before
calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so
fix it by incrementing sched_smt_present in the error path.
CVE-2024-44958
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not BUG_ON() when freeing tree block after error
When freeing a tree block, at btrfs_free_tree_block(), if we fail to
create a delayed reference we don't deal with the error and just do a
BUG_ON(). The error most likely to happen is -ENOMEM, and we have a
comment mentioning that only -ENOMEM can happen, but that is not true,
because in case qgroups are enabled any error returned from
btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned
from btrfs_search_slot() for example) can be propagated back to
btrfs_free_tree_block().
So stop doing a BUG_ON() and return the error to the callers and make
them abort the transaction to prevent leaking space. Syzbot was
triggering this, likely due to memory allocation failure injection.
CVE-2024-44963
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Prevent release of buffer in I/O
When a task waiting for completion of a Store Data operation is
interrupted, an attempt is made to halt this operation. If this attempt
fails due to a hardware or firmware problem, there is a chance that the
SCLP facility might store data into buffers referenced by the original
operation at a later time.
Handle this situation by not releasing the referenced data buffers if
the halt attempt fails. For current use cases, this might result in a
leak of few pages of memory in case of a rare hardware/firmware
malfunction.
CVE-2024-44969
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails
If the dpu_format_populate_layout() fails, then FB is prepared, but not
cleaned up. This ends up leaking the pin_count on the GEM object and
causes a splat during DRM file closure:
msm_obj->pin_count
WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc
[...]
Call trace:
update_lru_locked+0xc4/0xcc
put_pages+0xac/0x100
msm_gem_free_object+0x138/0x180
drm_gem_object_free+0x1c/0x30
drm_gem_object_handle_put_unlocked+0x108/0x10c
drm_gem_object_release_handle+0x58/0x70
idr_for_each+0x68/0xec
drm_gem_release+0x28/0x40
drm_file_free+0x174/0x234
drm_release+0xb0/0x160
__fput+0xc0/0x2c8
__fput_sync+0x50/0x5c
__arm64_sys_close+0x38/0x7c
invoke_syscall+0x48/0x118
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x4c/0x120
el0t_64_sync_handler+0x100/0x12c
el0t_64_sync+0x190/0x194
irq event stamp: 129818
hardirqs last enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124
hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c
softirqs last enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8
softirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20
Patchwork: https://patchwork.freedesktop.org/patch/600714/
CVE-2024-44982
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent UAF in ip6_send_skb()
syzbot reported an UAF in ip6_send_skb() [1]
After ip6_local_out() has returned, we no longer can safely
dereference rt, unless we hold rcu_read_lock().
A similar issue has been fixed in commit
a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")
Another potential issue in ip6_finish_output2() is handled in a
separate patch.
[1]
BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530
CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
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
ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588
rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x1a6/0x270 net/socket.c:745
sock_write_iter+0x2dd/0x400 net/socket.c:1160
do_iter_readv_writev+0x60a/0x890
vfs_writev+0x37c/0xbb0 fs/read_write.c:971
do_writev+0x1b1/0x350 fs/read_write.c:1018
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:0x7f936bf79e79
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79
RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004
RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8
</TASK>
Allocated by task 6530:
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:312 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3988 [inline]
slab_alloc_node mm/slub.c:4037 [inline]
kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044
dst_alloc+0x12b/0x190 net/core/dst.c:89
ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670
make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]
xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313
ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257
rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x1a6/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
___sys_sendmsg net/socket.c:2651 [inline]
__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
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 45:
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:579
poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
__kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2252 [inline]
slab_free mm/slub.c:4473 [inline]
kmem_cache_free+0x145/0x350 mm/slub.c:4548
dst_destroy+0x2ac/0x460 net/core/dst.c:124
rcu_do_batch kernel/rcu/tree.c:2569 [inline]
rcu_core+0xafd/0x1830 kernel/rcu/tree.
---truncated---
CVE-2024-44987
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix a deadlock problem when config TC during resetting
When config TC during the reset process, may cause a deadlock, the flow is
as below:
pf reset start
|
v
......
setup tc |
| v
v DOWN: napi_disable()
napi_disable()(skip) |
| |
v v
...... ......
| |
v |
napi_enable() |
v
UINIT: netif_napi_del()
|
v
......
|
v
INIT: netif_napi_add()
|
v
...... global reset start
| |
v v
UP: napi_enable()(skip) ......
| |
v v
...... napi_disable()
In reset process, the driver will DOWN the port and then UINIT, in this
case, the setup tc process will UP the port before UINIT, so cause the
problem. Adds a DOWN process in UINIT to fix it.
CVE-2024-44995
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: idt77252: prevent use after free in dequeue_rx()
We can't dereference "skb" after calling vcc->push() because the skb
is released.
CVE-2024-44998
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gtp: pull network headers in gtp_dev_xmit()
syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]
We must make sure the IPv4 or Ipv6 header is pulled in skb->head
before accessing fields in them.
Use pskb_inet_may_pull() to fix this issue.
[1]
BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]
BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
ipv6_pdp_find drivers/net/gtp.c:220 [inline]
gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
__netdev_start_xmit include/linux/netdevice.h:4913 [inline]
netdev_start_xmit include/linux/netdevice.h:4922 [inline]
xmit_one net/core/dev.c:3580 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596
__dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423
dev_queue_xmit include/linux/netdevice.h:3105 [inline]
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3145 [inline]
packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
__sys_sendto+0x685/0x830 net/socket.c:2204
__do_sys_sendto net/socket.c:2216 [inline]
__se_sys_sendto net/socket.c:2212 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3994 [inline]
slab_alloc_node mm/slub.c:4037 [inline]
kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
__alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
alloc_skb include/linux/skbuff.h:1320 [inline]
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815
packet_alloc_skb net/packet/af_packet.c:2994 [inline]
packet_snd net/packet/af_packet.c:3088 [inline]
packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:745
__sys_sendto+0x685/0x830 net/socket.c:2204
__do_sys_sendto net/socket.c:2216 [inline]
__se_sys_sendto net/socket.c:2212 [inline]
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
CVE-2024-44999
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Input: MT - limit max slots
syzbot is reporting too large allocation at input_mt_init_slots(), for
num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).
Since nobody knows possible max slots, this patch chose 1024.
CVE-2024-45008
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netem: fix return value if duplicate enqueue fails
There is a bug in netem_enqueue() introduced by
commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
that can lead to a use-after-free.
This commit made netem_enqueue() always return NET_XMIT_SUCCESS
when a packet is duplicated, which can cause the parent qdisc's q.qlen
to be mistakenly incremented. When this happens qlen_notify() may be
skipped on the parent during destruction, leaving a dangling pointer
for some classful qdiscs like DRR.
There are two ways for the bug happen:
- If the duplicated packet is dropped by rootq->enqueue() and then
the original packet is also dropped.
- If rootq->enqueue() sends the duplicated packet to a different qdisc
and the original packet is dropped.
In both cases NET_XMIT_SUCCESS is returned even though no packets
are enqueued at the netem qdisc.
The fix is to defer the enqueue of the duplicate packet until after
the original packet has been guaranteed to return NET_XMIT_SUCCESS.
CVE-2024-45016
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
memcg_write_event_control(): fix a user-triggerable oops
we are *not* guaranteed that anything past the terminating NUL
is mapped (let alone initialized with anything sane).
CVE-2024-45021
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
CVE-2024-45337
important
When logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists.
CVE-2024-45339
important
An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.
CVE-2024-45490
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).
CVE-2024-45491
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).
CVE-2024-45492
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
moderate
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: aacraid: Fix double-free on probe failure
aac_probe_one() calls hardware-specific init functions through the
aac_driver_ident::init pointer, all of which eventually call down to
aac_init_adapter().
If aac_init_adapter() fails after allocating memory for aac_dev::queues,
it frees the memory but does not clear that member.
After the hardware-specific init function returns an error,
aac_probe_one() goes down an error path that frees the memory pointed to
by aac_dev::queues, resulting.in a double-free.
CVE-2024-46673
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Prevent USB core invalid event buffer address access
This commit addresses an issue where the USB core could access an
invalid event buffer address during runtime suspend, potentially causing
SMMU faults and other memory issues in Exynos platforms. The problem
arises from the following sequence.
1. In dwc3_gadget_suspend, there is a chance of a timeout when
moving the USB core to the halt state after clearing the
run/stop bit by software.
2. In dwc3_core_exit, the event buffer is cleared regardless of
the USB core's status, which may lead to an SMMU faults and
other memory issues. if the USB core tries to access the event
buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures
that the event buffer address is not cleared by software when the USB
core is active during runtime suspend by checking its status before
clearing the buffer address.
CVE-2024-46675
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: Add poll mod list filling check
In case of im_protocols value is 1 and tm_protocols value is 0 this
combination successfully passes the check
'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().
But then after pn533_poll_create_mod_list() call in pn533_start_poll()
poll mod list will remain empty and dev->poll_mod_count will remain 0
which lead to division by zero.
Normally no im protocol has value 1 in the mask, so this combination is
not expected by driver. But these protocol values actually come from
userspace via Netlink interface (NFC_CMD_START_POLL operation). So a
broken or malicious program may pass a message containing a "bad"
combination of protocol parameter values so that dev->poll_mod_count
is not incremented inside pn533_poll_create_mod_list(), thus leading
to division by zero.
Call trace looks like:
nfc_genl_start_poll()
nfc_start_poll()
->start_poll()
pn533_start_poll()
Add poll mod list filling check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-46676
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix a potential NULL pointer dereference
When sockfd_lookup() fails, gtp_encap_enable_socket() returns a
NULL pointer, but its callers only check for error pointers thus miss
the NULL pointer case.
Fix it by returning an error pointer with the error code carried from
sockfd_lookup().
(I found this bug during code inspection.)
CVE-2024-46677
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ethtool: check device is present when getting link settings
A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:
[exception RIP: qed_get_current_link+17]
#8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
#9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
#10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
#11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
#12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
#13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
#14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
#15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
#16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
#17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb
crash> struct net_device.state ffff9a9d21336000
state = 5,
state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).
This is the same sort of panic as observed in commit 4224cfd7fb65
("net-sysfs: add check for netdevice being present to speed_show").
There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.
Move this check into ethtool to protect all callers.
CVE-2024-46679
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference in pcs_get_function()
pinmux_generic_get_function() can return NULL and the pointer 'function'
was dereferenced without checking against NULL. Add checking of pointer
'function' in pcs_get_function().
Found by code review.
CVE-2024-46685
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()
This happens when called from SMB2_read() while using rdma
and reaching the rdma_readwrite_threshold.
CVE-2024-46686
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Mark XDomain as unplugged when router is removed
I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.
However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.
CVE-2024-46702
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
On a system with a GICv3, if a guest hasn't been configured with
GICv3 and that the host is not capable of GICv2 emulation,
a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.
We therefore try to emulate the SGI access, only to hit a NULL
pointer as no private interrupt is allocated (no GIC, remember?).
The obvious fix is to give the guest what it deserves, in the
shape of a UNDEF exception.
CVE-2024-46707
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix AUX buffer serialization
Ole reported that event->mmap_mutex is strictly insufficient to
serialize the AUX buffer, add a per RB mutex to fully serialize it.
Note that in the lock order comment the perf_event::mmap_mutex order
was already wrong, that is, it nesting under mmap_lock is not new with
this patch.
CVE-2024-46713
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
driver: iio: add missing checks on iio_info's callback access
Some callbacks from iio_info structure are accessed without any check, so
if a driver doesn't implement them trying to access the corresponding
sysfs entries produce a kernel oops such as:
[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute
[...]
[ 2203.783416] Call trace:
[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48
[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120
[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4
[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0
[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4
[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54
[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)
[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000
[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000
[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0
[ 2203.830363] Code: bad PC value
[ 2203.832695] ---[ end trace 0000000000000000 ]---
CVE-2024-46715
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix possible NULL pointer dereference
profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made
from __create_missing_ancestors(..) and 'ent->old' is NULL in
aa_replace_profiles(..).
In that case, it must return an error code and the code, -ENOENT represents
its state that the path of its parent is not existed yet.
BUG: kernel NULL pointer dereference, address: 0000000000000030
PGD 0 P4D 0
PREEMPT SMP PTI
CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Call Trace:
<TASK>
? show_regs+0x6d/0x80
? __die+0x24/0x80
? page_fault_oops+0x99/0x1b0
? kernelmode_fixup_or_oops+0xb2/0x140
? __bad_area_nosemaphore+0x1a5/0x2c0
? find_vma+0x34/0x60
? bad_area_nosemaphore+0x16/0x30
? do_user_addr_fault+0x2a2/0x6b0
? exc_page_fault+0x83/0x1b0
? asm_exc_page_fault+0x27/0x30
? aafs_create.constprop.0+0x7f/0x130
? aafs_create.constprop.0+0x51/0x130
__aafs_profile_mkdir+0x3d6/0x480
aa_replace_profiles+0x83f/0x1270
policy_update+0xe3/0x180
profile_load+0xbc/0x150
? rw_verify_area+0x47/0x140
vfs_write+0x100/0x480
? __x64_sys_openat+0x55/0xa0
? syscall_exit_to_user_mode+0x86/0x260
ksys_write+0x73/0x100
__x64_sys_write+0x19/0x30
x64_sys_call+0x7e/0x25c0
do_syscall_64+0x7f/0x180
entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7be9f211c574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
</TASK>
Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
CR2: 0000000000000030
---[ end trace 0000000000000000 ]---
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000
---truncated---
CVE-2024-46721
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix mc_data out-of-bounds read warning
Clear warning that read mc_data[i-1] may out-of-bounds.
CVE-2024-46722
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ucode out-of-bounds read warning
Clear warning that read ucode[] may out-of-bounds.
CVE-2024-46723
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds
read error
CVE-2024-46724
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix the Out-of-bounds read warning
using index i - 1U may beyond element index
for mc_data[] when i = 0.
CVE-2024-46731
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: fix kernel crash if commands allocation fails
If the commands allocation fails in nvmet_tcp_alloc_cmds()
the kernel crashes in nvmet_tcp_release_queue_work() because of
a NULL pointer dereference.
nvmet: failed to install queue 0 cntlid 1 ret 6
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
Fix the bug by setting queue->nr_cmds to zero in case
nvmet_tcp_alloc_cmd() fails.
CVE-2024-46737
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
VMCI: Fix use-after-free when removing resource in vmci_resource_remove()
When removing a resource from vmci_resource_table in
vmci_resource_remove(), the search is performed using the resource
handle by comparing context and resource fields.
It is possible though to create two resources with different types
but same handle (same context and resource fields).
When trying to remove one of the resources, vmci_resource_remove()
may not remove the intended one, but the object will still be freed
as in the case of the datagram type in vmci_datagram_destroy_handle().
vmci_resource_table will still hold a pointer to this freed resource
leading to a use-after-free vulnerability.
BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106
print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
__kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425
kasan_report+0x38/0x51 mm/kasan/report.c:442
vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182
ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444
kref_put include/linux/kref.h:65 [inline]
vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195
vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
__fput+0x261/0xa34 fs/file_table.c:282
task_work_run+0xf0/0x194 kernel/task_work.c:164
tracehook_notify_resume include/linux/tracehook.h:189 [inline]
exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187
exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
__syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313
do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x6e/0x0
This change ensures the type is also checked when removing
the resource from vmci_resource_table in vmci_resource_remove().
CVE-2024-46738
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind
For primary VM Bus channels, primary_channel pointer is always NULL. This
pointer is valid only for the secondary channels. Also, rescind callback
is meant for primary channels only.
Fix NULL pointer dereference by retrieving the device_obj from the parent
for the primary channel.
CVE-2024-46739
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
of/irq: Prevent device address out-of-bounds read in interrupt map walk
When of_irq_parse_raw() is invoked with a device address smaller than
the interrupt parent node (from #address-cells property), KASAN detects
the following out-of-bounds read when populating the initial match table
(dyndbg="func of_irq_parse_* +p"):
OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0
OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2
OF: intspec=4
OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2
OF: -> addrsize=3
==================================================================
BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0
Read of size 4 at addr ffffff81beca5608 by task bash/764
CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1
Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023
Call trace:
dump_backtrace+0xdc/0x130
show_stack+0x1c/0x30
dump_stack_lvl+0x6c/0x84
print_report+0x150/0x448
kasan_report+0x98/0x140
__asan_load4+0x78/0xa0
of_irq_parse_raw+0x2b8/0x8d0
of_irq_parse_one+0x24c/0x270
parse_interrupts+0xc0/0x120
of_fwnode_add_links+0x100/0x2d0
fw_devlink_parse_fwtree+0x64/0xc0
device_add+0xb38/0xc30
of_device_add+0x64/0x90
of_platform_device_create_pdata+0xd0/0x170
of_platform_bus_create+0x244/0x600
of_platform_notify+0x1b0/0x254
blocking_notifier_call_chain+0x9c/0xd0
__of_changeset_entry_notify+0x1b8/0x230
__of_changeset_apply_notify+0x54/0xe4
of_overlay_fdt_apply+0xc04/0xd94
...
The buggy address belongs to the object at ffffff81beca5600
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 8 bytes inside of
128-byte region [ffffff81beca5600, ffffff81beca5680)
The buggy address belongs to the physical page:
page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4
head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0
flags: 0x8000000000010200(slab|head|zone=2)
raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
==================================================================
OF: -> got it !
Prevent the out-of-bounds read by copying the device address into a
buffer of sufficient size.
CVE-2024-46743
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: sanity check symbolic link size
Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.
This is caused by an uninitialised page, which is ultimately caused
by a corrupted symbolic link size read from disk.
The reason why the corrupted symlink size causes an uninitialised
page is due to the following sequence of events:
1. squashfs_read_inode() is called to read the symbolic
link from disk. This assigns the corrupted value
3875536935 to inode->i_size.
2. Later squashfs_symlink_read_folio() is called, which assigns
this corrupted value to the length variable, which being a
signed int, overflows producing a negative number.
3. The following loop that fills in the page contents checks that
the copied bytes is less than length, which being negative means
the loop is skipped, producing an uninitialised page.
This patch adds a sanity check which checks that the symbolic
link size is not larger than expected.
--
V2: fix spelling mistake.
CVE-2024-46744
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - reject requests with unreasonable number of slots
When exercising uinput interface syzkaller may try setting up device
with a really large number of slots, which causes memory allocation
failure in input_mt_init_slots(). While this allocation failure is
handled properly and request is rejected, it results in syzkaller
reports. Additionally, such request may put undue burden on the
system which will try to free a lot of memory for a bogus request.
Fix it by limiting allowed number of slots to 100. This can easily
be extended if we see devices that can track more than 100 contacts.
CVE-2024-46745
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: Add missing bridge lock to pci_bus_lock()
One of the true positives that the cfg_access_lock lockdep effort
identified is this sequence:
WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70
RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70
Call Trace:
<TASK>
? __warn+0x8c/0x190
? pci_bridge_secondary_bus_reset+0x5d/0x70
? report_bug+0x1f8/0x200
? handle_bug+0x3c/0x70
? exc_invalid_op+0x18/0x70
? asm_exc_invalid_op+0x1a/0x20
? pci_bridge_secondary_bus_reset+0x5d/0x70
pci_reset_bus+0x1d8/0x270
vmd_probe+0x778/0xa10
pci_device_probe+0x95/0x120
Where pci_reset_bus() users are triggering unlocked secondary bus resets.
Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses
pci_bus_lock() before issuing the reset which locks everything *but* the
bridge itself.
For the same motivation as adding:
bridge = pci_upstream_bridge(dev);
if (bridge)
pci_dev_lock(bridge);
to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add
pci_dev_lock() for @bus->self to pci_bus_lock().
[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:
https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]
CVE-2024-46750
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()
Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,
aborting the transaction and logging an error message.
CVE-2024-46751
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: replace BUG_ON() with error handling at update_ref_for_cow()
Instead of a BUG_ON() just return an error, log an error message and
abort the transaction in case we find an extent buffer belonging to the
relocation tree that doesn't have the full backref flag set. This is
unexpected and should never happen (save for bugs or a potential bad
memory).
CVE-2024-46752
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle errors from btrfs_dec_ref() properly
In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This is
incorrect, we have proper error handling here, return the error.
CVE-2024-46753
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()
mwifiex_get_priv_by_id() returns the priv pointer corresponding to
the bss_num and bss_type, but without checking if the priv is actually
currently in use.
Unused priv pointers do not have a wiphy attached to them which can
lead to NULL pointer dereferences further down the callstack. Fix
this by returning only used priv pointers which have priv->bss_mode
set to something else than NL80211_IFTYPE_UNSPECIFIED.
Said NULL pointer dereference happened when an Accesspoint was started
with wpa_supplicant -i mlan0 with this config:
network={
ssid="somessid"
mode=2
frequency=2412
key_mgmt=WPA-PSK WPA-PSK-SHA256
proto=RSN
group=CCMP
pairwise=CCMP
psk="12345678"
}
When waiting for the AP to be established, interrupting wpa_supplicant
with <ctrl-c> and starting it again this happens:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140
| Mem abort info:
| ESR = 0x0000000096000004
| EC = 0x25: DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| FSC = 0x04: level 0 translation fault
| Data abort info:
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000
| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio
+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs
+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6
| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18
| Hardware name: somemachine (DT)
| Workqueue: events sdio_irq_work
| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]
| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]
| sp : ffff8000818b3a70
| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004
| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9
| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000
| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000
| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517
| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1
| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157
| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124
| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000
| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000
| Call trace:
| mwifiex_get_cfp+0xd8/0x15c [mwifiex]
| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]
| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]
| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]
| mwifiex_process_event+0x110/0x238 [mwifiex]
| mwifiex_main_process+0x428/0xa44 [mwifiex]
| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]
| process_sdio_pending_irqs+0x64/0x1b8
| sdio_irq_work+0x4c/0x7c
| process_one_work+0x148/0x2a0
| worker_thread+0x2fc/0x40c
| kthread+0x110/0x114
| ret_from_fork+0x10/0x20
| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)
| ---[ end trace 0000000000000000 ]---
CVE-2024-46755
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (adc128d818) Fix underflows seen when writing limit attributes
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
CVE-2024-46759
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv
The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.
The crash occurs because although the MSI data structure has been
released during disable/hot-unplug path and it has been assigned
with NULL, still during unregistration the code was again trying to
explicitly disable the MSI which causes the NULL pointer dereference and
kernel crash.
The patch fixes the check during unregistration path to prevent invoking
pci_disable_msi/msix() since its data structure is already freed.
CVE-2024-46761
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fou: Fix null-ptr-deref in GRO.
We observed a null-ptr-deref in fou_gro_receive() while shutting down
a host. [0]
The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol
in struct fou.
When fou_release() is called due to netns dismantle or explicit tunnel
teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.
Then, the tunnel socket is destroyed after a single RCU grace period.
So, in-flight udp4_gro_receive() could find the socket and execute the
FOU GRO handler, where sk->sk_user_data could be NULL.
Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL
checks in FOU GRO handlers.
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0
SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1
Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017
RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]
Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42
RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297
RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010
RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08
RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002
R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400
R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0
FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<IRQ>
? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)
? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)
? no_context (arch/x86/mm/fault.c:752)
? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)
? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)
? fou_gro_receive (net/ipv4/fou.c:233) [fou]
udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)
udp4_gro_receive (net/ipv4/udp_offload.c:604)
inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))
dev_gro_receive (net/core/dev.c:6035 (discriminator 4))
napi_gro_receive (net/core/dev.c:6170)
ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]
ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]
napi_poll (net/core/dev.c:6847)
net_rx_action (net/core/dev.c:6917)
__do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)
asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)
</IRQ>
do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)
irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)
common_interrupt (arch/x86/kernel/irq.c:239)
asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)
RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)
Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246
RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900
RDX: ffff93daee800000 RSI: ffff93d
---truncated---
CVE-2024-46763
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ice: Add netif_device_attach/detach into PF reset flow
Ethtool callbacks can be executed while reset is in progress and try to
access deleted resources, e.g. getting coalesce settings can result in a
NULL pointer dereference seen below.
Reproduction steps:
Once the driver is fully initialized, trigger reset:
# echo 1 > /sys/class/net/<interface>/device/reset
when reset is in progress try to get coalesce settings using ethtool:
# ethtool -c <interface>
BUG: kernel NULL pointer dereference, address: 0000000000000020
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7
RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]
RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206
RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000
R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40
FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0
Call Trace:
<TASK>
ice_get_coalesce+0x17/0x30 [ice]
coalesce_prepare_data+0x61/0x80
ethnl_default_doit+0xde/0x340
genl_family_rcv_msg_doit+0xf2/0x150
genl_rcv_msg+0x1b3/0x2c0
netlink_rcv_skb+0x5b/0x110
genl_rcv+0x28/0x40
netlink_unicast+0x19c/0x290
netlink_sendmsg+0x222/0x490
__sys_sendto+0x1df/0x1f0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x82/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7faee60d8e27
Calling netif_device_detach() before reset makes the net core not call
the driver when ethtool command is issued, the attempt to execute an
ethtool command during reset will result in the following message:
netlink error: No such device
instead of NULL pointer dereference. Once reset is done and
ice_rebuild() is executing, the netif_device_attach() is called to allow
for ethtool operations to occur again in a safe manner.
CVE-2024-46770
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()
Smatch warns:
arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
spectre issue 'args.args' [r] (local cap)
The 'nargs' and 'nret' locals come directly from a user-supplied
buffer and are used as indexes into a small stack-based array and as
inputs to copy_to_user() after they are subject to bounds checks.
Use array_index_nospec() after the bounds checks to clamp these values
for speculative execution.
CVE-2024-46774
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
udf: Avoid excessive partition lengths
Avoid mounting filesystems where the partition would overflow the
32-bits used for block number. Also refuse to mount filesystems where
the partition length is so large we cannot safely index bits in a
block bitmap.
CVE-2024-46777
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: fix return value of tcp_bpf_sendmsg()
When we cork messages in psock->cork, the last message triggers the
flushing will result in sending a sk_msg larger than the current
message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes
negative at least in the following case:
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); // <==== HERE
473 return -EACCES;
Therefore, it could lead to the following BUG with a proper value of
'copied' (thanks to syzbot). We should not use negative 'copied' as a
return value here.
------------[ cut here ]------------
kernel BUG at net/socket.c:733!
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0
Hardware name: linux,dummy-virt (DT)
pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : sock_sendmsg_nosec net/socket.c:733 [inline]
pc : sock_sendmsg_nosec net/socket.c:728 [inline]
pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745
lr : sock_sendmsg_nosec net/socket.c:730 [inline]
lr : __sock_sendmsg+0x54/0x60 net/socket.c:745
sp : ffff800088ea3b30
x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000
x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000
x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90
x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001
x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0
x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000
x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef
Call trace:
sock_sendmsg_nosec net/socket.c:733 [inline]
__sock_sendmsg+0x5c/0x60 net/socket.c:745
____sys_sendmsg+0x274/0x2ac net/socket.c:2597
___sys_sendmsg+0xac/0x100 net/socket.c:2651
__sys_sendmsg+0x84/0xe0 net/socket.c:2680
__do_sys_sendmsg net/socket.c:2689 [inline]
__se_sys_sendmsg net/socket.c:2687 [inline]
__arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49
el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132
do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151
el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598
Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)
---[ end trace 0000000000000000 ]---
CVE-2024-46783
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup
Currently napi_disable() gets called during rxq and txq cleanup,
even before napi is enabled and hrtimer is initialized. It causes
kernel panic.
? page_fault_oops+0x136/0x2b0
? page_counter_cancel+0x2e/0x80
? do_user_addr_fault+0x2f2/0x640
? refill_obj_stock+0xc4/0x110
? exc_page_fault+0x71/0x160
? asm_exc_page_fault+0x27/0x30
? __mmdrop+0x10/0x180
? __mmdrop+0xec/0x180
? hrtimer_active+0xd/0x50
hrtimer_try_to_cancel+0x2c/0xf0
hrtimer_cancel+0x15/0x30
napi_disable+0x65/0x90
mana_destroy_rxq+0x4c/0x2f0
mana_create_rxq.isra.0+0x56c/0x6d0
? mana_uncfg_vport+0x50/0x50
mana_alloc_queues+0x21b/0x320
? skb_dequeue+0x5f/0x80
CVE-2024-46784
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: fix checks for huge PMDs
Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.
The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:
1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
the right two race windows) - I've tested this in a kernel build with
some extra mdelay() calls. See the commit message for a description
of the race scenario.
On older kernels (before 6.5), I think the same bug can even
theoretically lead to accessing transhuge page contents as a page table
if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
detecting PMDs that don't point to page tables.
On older kernels (before 6.5), you'd just have to win a single fairly
wide race to hit this.
I've tested this on 6.1 stable by racing migration (with a mdelay()
patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed
to yank page tables out from under us (though I haven't tested that),
so I think the BUG_ON() checks in mfill_atomic() are just wrong.
I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backported to kernels
affected by bugs 1+2.
This patch (of 2):
This fixes two issues.
I discovered that the following race can occur:
mfill_atomic other thread
============ ============
<zap PMD>
pmdp_get_lockless() [reads none pmd]
<bail if trans_huge>
<if none:>
<pagefault creates transhuge zeropage>
__pte_alloc [no-op]
<zap PMD>
<bail if pmd_trans_huge(*dst_pmd)>
BUG_ON(pmd_none(*dst_pmd))
I have experimentally verified this in a kernel with extra mdelay() calls;
the BUG_ON(pmd_none(*dst_pmd)) triggers.
On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow
pte_offset_map[_lock]() to fail"), this can't lead to anything worse than
a BUG_ON(), since the page table access helpers are actually designed to
deal with page tables concurrently disappearing; but on older kernels
(<=6.4), I think we could probably theoretically race past the two
BUG_ON() checks and end up treating a hugepage as a page table.
The second issue is that, as Qi Zheng pointed out, there are other types
of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs
(in particular, migration PMDs).
On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a
PMD that contains a migration entry (which just requires winning a single,
fairly wide race), it will pass the PMD to pte_offset_map_lock(), which
assumes that the PMD points to a page table.
Breakage follows: First, the kernel tries to take the PTE lock (which will
crash or maybe worse if there is no "struct page" for the address bits in
the migration entry PMD - I think at least on X86 there usually is no
corresponding "struct page" thanks to the PTE inversion mitigation, amd64
looks different).
If that didn't crash, the kernel would next try to write a PTE into what
it wrongly thinks is a page table.
As part of fixing these issues, get rid of the check for pmd_trans_huge()
before __pte_alloc() - that's redundant, we're going to have to check for
that after the __pte_alloc() anyway.
Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.
CVE-2024-46787
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sch/netem: fix use after free in netem_dequeue
If netem_dequeue() enqueues packet to inner qdisc and that qdisc
returns __NET_XMIT_STOLEN. The packet is dropped but
qdisc_tree_reduce_backlog() is not called to update the parent's
q.qlen, leading to the similar use-after-free as Commit
e04991a48dbaf382 ("netem: fix return value if duplicate enqueue
fails")
Commands to trigger KASAN UaF:
ip link add type dummy
ip link set lo up
ip link set dummy0 up
tc qdisc add dev lo parent root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2: handle 3: drr
tc filter add dev lo parent 3: basic classid 3:1 action mirred egress
redirect dev dummy0
tc class add dev lo classid 3:1 drr
ping -c1 -W0.01 localhost # Trigger bug
tc class del dev lo classid 1:1
tc class add dev lo classid 1:1 drr
ping -c1 -W0.01 localhost # UaF
CVE-2024-46800
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: added NULL check at start of dc_validate_stream
[Why]
prevent invalid memory access
[How]
check if dc and stream are NULL
CVE-2024-46802
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check BIOS images before it is used
BIOS images may fail to load and null checks are added before they are
used.
This fixes 6 NULL_RETURNS issues reported by Coverity.
CVE-2024-46809
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check link_index before accessing dc->links[]
[WHY & HOW]
dc->links[] has max size of MAX_LINKS and NULL is return when trying to
access with out-of-bound index.
This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.
CVE-2024-46813
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links
[Why]
Coverity report OVERRUN warning. There are
only max_links elements within dc->links. link
count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.
[How]
Make sure link count less than max_links.
CVE-2024-46816
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check gpio_id before used as array index
[WHY & HOW]
GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore
should be checked in advance.
This fixes 5 OVERRUN issues reported by Coverity.
CVE-2024-46818
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
In a review discussion of the changes to support vCPU hotplug where
a check was added on the GICC being enabled if was online, it was
noted that there is need to map back to the cpu and use that to index
into a cpumask. As such, a valid ID is needed.
If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
for the entry in cpu_madt_gicc[cpu] == NULL. This function would
then cause a NULL pointer dereference. Whilst a path to trigger
this has not been established, harden this caller against the
possibility.
CVE-2024-46822
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ELF: fix kernel.randomize_va_space double read
ELF loader uses "randomize_va_space" twice. It is sysctl and can change
at any moment, so 2 loads could see 2 different values in theory with
unpredictable consequences.
Issue exactly one load for consistent value across one exec.
CVE-2024-46826
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ethtool: fail closed if we can't get max channel used in indirection tables
Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with
active RSS contexts") proves that allowing indirection table to contain
channels with out of bounds IDs may lead to crashes. Currently the
max channel check in the core gets skipped if driver can't fetch
the indirection table or when we can't allocate memory.
Both of those conditions should be extremely rare but if they do
happen we should try to be safe and fail the channel change.
CVE-2024-46834
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: clean up our handling of refs == 0 in snapshot delete
In reada we BUG_ON(refs == 0), which could be unkind since we aren't
holding a lock on the extent leaf and thus could get a transient
incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which
could happen if we have extent tree corruption. Change that to return
-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,
however we return -EIO, which -EUCLEAN is a more appropriate error code.
Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert
that to proper error handling. Also adjust the error message so we can
actually do something with the information.
CVE-2024-46840
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()
We handle errors here properly, ENOMEM isn't fatal, return the error.
CVE-2024-46841
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Limit the period on Haswell
Running the ltp test cve-2015-3290 concurrently reports the following
warnings.
perfevents: irq loop stuck!
WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
intel_pmu_handle_irq+0x285/0x370
Call Trace:
<NMI>
? __warn+0xa4/0x220
? intel_pmu_handle_irq+0x285/0x370
? __report_bug+0x123/0x130
? intel_pmu_handle_irq+0x285/0x370
? __report_bug+0x123/0x130
? intel_pmu_handle_irq+0x285/0x370
? report_bug+0x3e/0xa0
? handle_bug+0x3c/0x70
? exc_invalid_op+0x18/0x50
? asm_exc_invalid_op+0x1a/0x20
? irq_work_claim+0x1e/0x40
? intel_pmu_handle_irq+0x285/0x370
perf_event_nmi_handler+0x3d/0x60
nmi_handle+0x104/0x330
Thanks to Thomas Gleixner's analysis, the issue is caused by the low
initial period (1) of the frequency estimation algorithm, which triggers
the defects of the HW, specifically erratum HSW11 and HSW143. (For the
details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)
The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL
event, but the initial period in the freq mode is 1. The erratum is the
same as the BDM11, which has been supported in the kernel. A minimum
period of 128 is enforced as well on HSW.
HSW143 is regarding that the fixed counter 1 may overcount 32 with the
Hyper-Threading is enabled. However, based on the test, the hardware
has more issues than it tells. Besides the fixed counter 1, the message
'interrupt took too long' can be observed on any counter which was armed
with a period < 32 and two events expired in the same NMI. A minimum
period of 32 is enforced for the rest of the events.
The recommended workaround code of the HSW143 is not implemented.
Because it only addresses the issue for the fixed counter. It brings
extra overhead through extra MSR writing. No related overcounting issue
has been reported so far.
CVE-2024-46848
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
spi: nxp-fspi: fix the KASAN report out-of-bounds bug
Change the memcpy length to fix the out-of-bounds issue when writing the
data that is not 4 byte aligned to TX FIFO.
To reproduce the issue, write 3 bytes data to NOR chip.
dd if=3b of=/dev/mtd0
[ 36.926103] ==================================================================
[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838
[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455
[ 36.946721]
[ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070
[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)
[ 36.961260] Call trace:
[ 36.963723] dump_backtrace+0x90/0xe8
[ 36.967414] show_stack+0x18/0x24
[ 36.970749] dump_stack_lvl+0x78/0x90
[ 36.974451] print_report+0x114/0x5cc
[ 36.978151] kasan_report+0xa4/0xf0
[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28
[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838
[ 36.990800] spi_mem_exec_op+0x8ec/0xd30
[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0
[ 36.999323] spi_mem_dirmap_write+0x238/0x32c
[ 37.003710] spi_nor_write_data+0x220/0x374
[ 37.007932] spi_nor_write+0x110/0x2e8
[ 37.011711] mtd_write_oob_std+0x154/0x1f0
[ 37.015838] mtd_write_oob+0x104/0x1d0
[ 37.019617] mtd_write+0xb8/0x12c
[ 37.022953] mtdchar_write+0x224/0x47c
[ 37.026732] vfs_write+0x1e4/0x8c8
[ 37.030163] ksys_write+0xec/0x1d0
[ 37.033586] __arm64_sys_write+0x6c/0x9c
[ 37.037539] invoke_syscall+0x6c/0x258
[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c
[ 37.046244] do_el0_svc+0x44/0x5c
[ 37.049589] el0_svc+0x38/0x78
[ 37.052681] el0t_64_sync_handler+0x13c/0x158
[ 37.057077] el0t_64_sync+0x190/0x194
[ 37.060775]
[ 37.062274] Allocated by task 455:
[ 37.065701] kasan_save_stack+0x2c/0x54
[ 37.069570] kasan_save_track+0x20/0x3c
[ 37.073438] kasan_save_alloc_info+0x40/0x54
[ 37.077736] __kasan_kmalloc+0xa0/0xb8
[ 37.081515] __kmalloc_noprof+0x158/0x2f8
[ 37.085563] mtd_kmalloc_up_to+0x120/0x154
[ 37.089690] mtdchar_write+0x130/0x47c
[ 37.093469] vfs_write+0x1e4/0x8c8
[ 37.096901] ksys_write+0xec/0x1d0
[ 37.100332] __arm64_sys_write+0x6c/0x9c
[ 37.104287] invoke_syscall+0x6c/0x258
[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c
[ 37.112972] do_el0_svc+0x44/0x5c
[ 37.116319] el0_svc+0x38/0x78
[ 37.119401] el0t_64_sync_handler+0x13c/0x158
[ 37.123788] el0t_64_sync+0x190/0x194
[ 37.127474]
[ 37.128977] The buggy address belongs to the object at ffff00081037c2a0
[ 37.128977] which belongs to the cache kmalloc-8 of size 8
[ 37.141177] The buggy address is located 0 bytes inside of
[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)
[ 37.153465]
[ 37.154971] The buggy address belongs to the physical page:
[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c
[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)
[ 37.175149] page_type: 0xfdffffff(slab)
[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000
[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000
[ 37.194553] page dumped because: kasan: bad access detected
[ 37.200144]
[ 37.201647] Memory state around the buggy address:
[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc
[ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc
[ 37.228186] ^
[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 37.246962] ==============================================================
---truncated---
CVE-2024-46853
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: dpaa: Pad packets to ETH_ZLEN
When sending packets under 60 bytes, up to three bytes of the buffer
following the data may be leaked. Avoid this by extending all packets to
ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be
reproduced by running
$ ping -s 11 destination
CVE-2024-46854
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses
The panasonic laptop code in various places uses the SINF array with index
values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array
is big enough.
Not all panasonic laptops have this many SINF array entries, for example
the Toughbook CF-18 model only has 10 SINF array entries. So it only
supports the AC+DC brightness entries and mute.
Check that the SINF array has a minimum size which covers all AC+DC
brightness entries and refuse to load if the SINF array is smaller.
For higher SINF indexes hide the sysfs attributes when the SINF array
does not contain an entry for that attribute, avoiding show()/store()
accessing the array out of bounds and add bounds checking to the probe()
and resume() code accessing these.
CVE-2024-46859
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
CVE-2024-47081
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-requests-2.24.0-8.23.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-requests-2.24.0-8.20.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."
CVE-2024-47220
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libruby2_1-2_1-2.1.9-19.9.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:ruby2.1-2.1.9-19.9.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:ruby2.1-stdlib-2.1.9-19.9.1
important
Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause
memory to be accessed that was previously freed in some situations
Impact summary: A use after free can have a range of potential consequences such
as the corruption of valid data, crashes or execution of arbitrary code.
However, only applications that directly call the SSL_free_buffers function are
affected by this issue. Applications that do not call this function are not
vulnerable. Our investigations indicate that this function is rarely used by
applications.
The SSL_free_buffers function is used to free the internal OpenSSL buffer used
when processing an incoming record from the network. The call is only expected
to succeed if the buffer is not currently in use. However, two scenarios have
been identified where the buffer is freed even when still in use.
The first scenario occurs where a record header has been received from the
network and processed by OpenSSL, but the full record body has not yet arrived.
In this case calling SSL_free_buffers will succeed even though a record has only
been partially processed and the buffer is still in use.
The second scenario occurs where a full record containing application data has
been received and processed by OpenSSL but the application has only read part of
this data. Again a call to SSL_free_buffers will succeed even though the buffer
is still in use.
While these scenarios could occur accidentally during normal operation a
malicious attacker could attempt to engineer a stituation where this occurs.
We are not aware of this issue being actively exploited.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
CVE-2024-4741
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
important
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: clear PARENT_WATCHED flags lazily
In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode->i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.
Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.
When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child.
CVE-2024-47660
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-47672
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
Not doing so will make us send a host command to the transport while the
firmware is not alive, which will trigger a WARNING.
bad state = 0
WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
Call Trace:
<TASK>
iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]
iwl_mvm_config_scan+0x198/0x260 [iwlmvm]
iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]
iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]
process_one_work+0x29e/0x640
worker_thread+0x2df/0x690
? rescuer_thread+0x540/0x540
kthread+0x192/0x1e0
? set_kthread_struct+0x90/0x90
ret_from_fork+0x22/0x30
CVE-2024-47673
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid leaving partial pfn mappings around in error case
As Jann points out, PFN mappings are special, because unlike normal
memory mappings, there is no lifetime information associated with the
mapping - it is just a raw mapping of PFNs with no reference counting of
a 'struct page'.
That's all very much intentional, but it does mean that it's easy to
mess up the cleanup in case of errors. Yes, a failed mmap() will always
eventually clean up any partial mappings, but without any explicit
lifetime in the page table mapping itself, it's very easy to do the
error handling in the wrong order.
In particular, it's easy to mistakenly free the physical backing store
before the page tables are actually cleaned up and (temporarily) have
stale dangling PTE entries.
To make this situation less error-prone, just make sure that any partial
pfn mapping is torn down early, before any other error handling.
CVE-2024-47674
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
icmp: change the order of rate limits
ICMP messages are ratelimited :
After the blamed commits, the two rate limiters are applied in this order:
1) host wide ratelimit (icmp_global_allow())
2) Per destination ratelimit (inetpeer based)
In order to avoid side-channels attacks, we need to apply
the per destination check first.
This patch makes the following change :
1) icmp_global_allow() checks if the host wide limit is reached.
But credits are not yet consumed. This is deferred to 3)
2) The per destination limit is checked/updated.
This might add a new node in inetpeer tree.
3) icmp_global_consume() consumes tokens if prior operations succeeded.
This means that host wide ratelimit is still effective
in keeping inetpeer tree small even under DDOS.
As a bonus, I removed icmp_global.lock as the fast path
can use a lock-free operation.
CVE-2024-47678
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vfs: fix race between evice_inodes() and find_inode()&iput()
Hi, all
Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().
cpu0: cpu1:
iput() // i_count is 1
->spin_lock(inode)
->dec i_count to 0
->iput_final() generic_shutdown_super()
->__inode_add_lru() ->evict_inodes()
// cause some reason[2] ->if (atomic_read(inode->i_count)) continue;
// return before // inode 261 passed the above check
// list_lru_add_obj() // and then schedule out
->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set
btrfs_iget()
// after some function calls
->find_inode()
// found the above inode 261
->spin_lock(inode)
// check I_FREEING|I_WILL_FREE
// and passed
->__iget()
->spin_unlock(inode) // schedule back
->spin_lock(inode)
// check (I_NEW|I_FREEING|I_WILL_FREE) flags,
// passed and set I_FREEING
iput() ->spin_unlock(inode)
->spin_lock(inode) ->evict()
// dec i_count to 0
->iput_final()
->spin_unlock()
->evict()
Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().
To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.
CVE-2024-47679
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: check skb is non-NULL in tcp_rto_delta_us()
We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic
kernel that are running ceph and recently hit a null ptr dereference in
tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also
saw it getting hit from the RACK case as well. Here are examples of the oops
messages we saw in each of those cases:
Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020
Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode
Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page
Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0
Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI
Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu
Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246
Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60
Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8
Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900
Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30
Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000
Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0
Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554
Jul 26 15:05:02 rx [11061395.916786] Call Trace:
Jul 26 15:05:02 rx [11061395.919488]
Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f
Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9
Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380
Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0
Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50
Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0
Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20
Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450
Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140
Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90
Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0
Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40
Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220
Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240
Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0
Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240
Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130
Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280
Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10
Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30
Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even
---truncated---
CVE-2024-47684
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()
syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending
garbage on the four reserved tcp bits (th->res1)
Use skb_put_zero() to clear the whole TCP header,
as done in nf_reject_ip_tcphdr_put()
BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
NF_HOOK include/linux/netfilter.h:312 [inline]
ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
__netif_receive_skb_one_core net/core/dev.c:5661 [inline]
__netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
process_backlog+0x4ad/0xa50 net/core/dev.c:6108
__napi_poll+0xe7/0x980 net/core/dev.c:6772
napi_poll net/core/dev.c:6841 [inline]
net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
__do_softirq+0x14/0x1a kernel/softirq.c:588
do_softirq+0x9a/0x100 kernel/softirq.c:455
__local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]
__dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450
dev_queue_xmit include/linux/netdevice.h:3105 [inline]
neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
__ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247
dst_output include/net/dst.h:450 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366
inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135
__tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466
tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143
tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333
__inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679
inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750
__sys_connect_file net/socket.c:2061 [inline]
__sys_connect+0x606/0x690 net/socket.c:2078
__do_sys_connect net/socket.c:2088 [inline]
__se_sys_connect net/socket.c:2085 [inline]
__x64_sys_connect+0x91/0xe0 net/socket.c:2085
x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was stored to memory at:
nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249
nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
NF_HOOK include/linux/netfilter.h:312 [inline]
ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
__netif_receive_skb_one_core
---truncated---
CVE-2024-47685
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency
In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to
destroying CM IDs"), the function flush_workqueue is invoked to flush the
work queue iwcm_wq.
But at that time, the work queue iwcm_wq was created via the function
alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.
Because the current process is trying to flush the whole iwcm_wq, if
iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current
process is not reclaiming memory or running on a workqueue which doesn't
have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee
leading to a deadlock.
The call trace is as below:
[ 125.350876][ T1430] Call Trace:
[ 125.356281][ T1430] <TASK>
[ 125.361285][ T1430] ? __warn (kernel/panic.c:693)
[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)
[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)
[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)
[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)
[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm
[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)
[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm
[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma
[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma
[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)
[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)
[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)
[ 125.531837][ T1430] kthread (kernel/kthread.c:389)
[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)
[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
[ 125.566487][ T1430] </TASK>
[ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---
CVE-2024-47696
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error
Ensure index in rtl2830_pid_filter does not exceed 31 to prevent
out-of-bounds access.
dev->filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index > 32 to index >= 32 to resolve this
issue.
CVE-2024-47697
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
Ensure index in rtl2832_pid_filter does not exceed 31 to prevent
out-of-bounds access.
dev->filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index > 32 to index >= 32 to resolve this
issue.
[hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]
CVE-2024-47698
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: fix possible UAF for bfqq->bic with merge chain
1) initial state, three tasks:
Process 1 Process 2 Process 3
(BIC1) (BIC2) (BIC3)
| ^ | ^ | ^
| | | | | |
V | V | V |
bfqq1 bfqq2 bfqq3
process ref: 1 1 1
2) bfqq1 merged to bfqq2:
Process 1 Process 2 Process 3
(BIC1) (BIC2) (BIC3)
| | | ^
\--------------\| | |
V V |
bfqq1--------->bfqq2 bfqq3
process ref: 0 2 1
3) bfqq2 merged to bfqq3:
Process 1 Process 2 Process 3
(BIC1) (BIC2) (BIC3)
here -> ^ | |
\--------------\ \-------------\|
V V
bfqq1--------->bfqq2---------->bfqq3
process ref: 0 1 3
In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then
get bfqq3 through merge chain, and finially handle IO by bfqq3.
Howerver, current code will think bfqq2 is owned by BIC1, like initial
state, and set bfqq2->bic to BIC1.
bfq_insert_request
-> by Process 1
bfqq = bfq_init_rq(rq)
bfqq = bfq_get_bfqq_handle_split
bfqq = bic_to_bfqq
-> get bfqq2 from BIC1
bfqq->ref++
rq->elv.priv[0] = bic
rq->elv.priv[1] = bfqq
if (bfqq_process_refs(bfqq) == 1)
bfqq->bic = bic
-> record BIC1 to bfqq2
__bfq_insert_request
new_bfqq = bfq_setup_cooperator
-> get bfqq3 from bfqq2->new_bfqq
bfqq_request_freed(bfqq)
new_bfqq->ref++
rq->elv.priv[1] = new_bfqq
-> handle IO by bfqq3
Fix the problem by checking bfqq is from merge chain fist. And this
might fix a following problem reported by our syzkaller(unreproducible):
==================================================================
BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595
CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Workqueue: kblockd blk_mq_requeue_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0x10d/0x610 mm/kasan/report.c:475
kasan_report+0x8e/0xc0 mm/kasan/report.c:588
bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757
bfq_init_rq block/bfq-iosched.c:6876 [inline]
bfq_insert_request block/bfq-iosched.c:6254 [inline]
bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304
blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593
blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502
process_one_work kernel/workqueue.c:2627 [inline]
process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
kthread+0x33c/0x440 kernel/kthread.c:388
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
</TASK>
Allocated by task 20776:
kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
__kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328
kasan_slab_alloc include/linux/kasan.h:188 [inline]
slab_post_alloc_hook mm/slab.h:763 [inline]
slab_alloc_node mm/slub.c:3458 [inline]
kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503
ioc_create_icq block/blk-ioc.c:370 [inline]
---truncated---
CVE-2024-47706
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()
Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,
as spotted by syzbot:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c
R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18
R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930
FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856
addrconf_notify+0x3cb/0x1020
notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
call_netdevice_notifiers net/core/dev.c:2046 [inline]
unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352
unregister_netdevice_many net/core/dev.c:11414 [inline]
unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289
unregister_netdevice include/linux/netdevice.h:3129 [inline]
__tun_detach+0x6b9/0x1600 drivers/net/tun.c:685
tun_detach drivers/net/tun.c:701 [inline]
tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510
__fput+0x24a/0x8a0 fs/file_table.c:422
task_work_run+0x24f/0x310 kernel/task_work.c:228
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0xa2f/0x27f0 kernel/exit.c:882
do_group_exit+0x207/0x2c0 kernel/exit.c:1031
__do_sys_exit_group kernel/exit.c:1042 [inline]
__se_sys_exit_group kernel/exit.c:1040 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1acc77def9
Code: Unable to access opcode bytes at 0x7f1acc77decf.
RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043
RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
R
---truncated---
CVE-2024-47707
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()
Since '__dev_queue_xmit()' should be called with interrupts enabled,
the following backtrace:
ieee80211_do_stop()
...
spin_lock_irqsave(&local->queue_stop_reason_lock, flags)
...
ieee80211_free_txskb()
ieee80211_report_used_skb()
ieee80211_report_ack_skb()
cfg80211_mgmt_tx_status_ext()
nl80211_frame_tx_status()
genlmsg_multicast_netns()
genlmsg_multicast_netns_filtered()
nlmsg_multicast_filtered()
netlink_broadcast_filtered()
do_one_broadcast()
netlink_broadcast_deliver()
__netlink_sendskb()
netlink_deliver_tap()
__netlink_deliver_tap_skb()
dev_queue_xmit()
__dev_queue_xmit() ; with IRQS disabled
...
spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)
issues the warning (as reported by syzbot reproducer):
WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120
Fix this by implementing a two-phase skb reclamation in
'ieee80211_do_stop()', where actual work is performed
outside of a section with interrupts disabled.
CVE-2024-47713
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled
Fix missuse of spin_lock_irq()/spin_unlock_irq() when
spin_lock_irqsave()/spin_lock_irqrestore() was hold.
This was discovered through the lock debugging, and the corresponding
log is as follows:
raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40
...
Call trace:
warn_bogus_irq_restore+0x30/0x40
_raw_spin_unlock_irqrestore+0x84/0xc8
add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]
hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]
hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]
create_qp+0x138/0x258
ib_create_qp_kernel+0x50/0xe8
create_mad_qp+0xa8/0x128
ib_mad_port_open+0x218/0x448
ib_mad_init_device+0x70/0x1f8
add_client_context+0xfc/0x220
enable_device_and_get+0xd0/0x140
ib_register_device.part.0+0xf4/0x1c8
ib_register_device+0x34/0x50
hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]
hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]
__hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]
hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]
CVE-2024-47735
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: call cache_put if xdr_reserve_space returns NULL
If not enough buffer space available, but idmap_lookup has triggered
lookup_fn which calls cache_get and returns successfully. Then we
missed to call cache_put here which pairs with cache_get.
Reviwed-by: Jeff Layton <jlayton@kernel.org>
CVE-2024-47737
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: Block path traversal
Most firmware names are hardcoded strings, or are constructed from fairly
constrained format strings where the dynamic parts are just some hex
numbers or such.
However, there are a couple codepaths in the kernel where firmware file
names contain string components that are passed through from a device or
semi-privileged userspace; the ones I could find (not counting interfaces
that require root privileges) are:
- lpfc_sli4_request_firmware_update() seems to construct the firmware
filename from "ModelName", a string that was previously parsed out of
some descriptor ("Vital Product Data") in lpfc_fill_vpd()
- nfp_net_fw_find() seems to construct a firmware filename from a model
name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I
think parses some descriptor that was read from the device.
(But this case likely isn't exploitable because the format string looks
like "netronome/nic_%s", and there shouldn't be any *folders* starting
with "netronome/nic_". The previous case was different because there,
the "%s" is *at the start* of the format string.)
- module_flash_fw_schedule() is reachable from the
ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
enough to pass the privilege check), and takes a userspace-provided
firmware name.
(But I think to reach this case, you need to have CAP_NET_ADMIN over a
network namespace that a special kind of ethernet device is mapped into,
so I think this is not a viable attack path in practice.)
Fix it by rejecting any firmware names containing ".." path components.
For what it's worth, I went looking and haven't found any USB device
drivers that use the firmware loader dangerously.
CVE-2024-47742
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mm: call the security_mmap_file() LSM hook in remap_file_pages()
The remap_file_pages syscall handler calls do_mmap() directly, which
doesn't contain the LSM security check. And if the process has called
personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
RW pages, this will actually result in remapping the pages to RWX,
bypassing a W^X policy enforced by SELinux.
So we should check prot by security_mmap_file LSM hook in the
remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
potentially permits an attacker to bypass a W^X policy enforced by
SELinux.
The bypass is similar to CVE-2016-10044, which bypass the same thing via
AIO and can be found in [1].
The PoC:
$ cat > test.c
int main(void) {
size_t pagesz = sysconf(_SC_PAGE_SIZE);
int mfd = syscall(SYS_memfd_create, "test", 0);
const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
MAP_SHARED, mfd, 0);
unsigned int old = syscall(SYS_personality, 0xffffffff);
syscall(SYS_personality, READ_IMPLIES_EXEC | old);
syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
syscall(SYS_personality, old);
// show the RWX page exists even if W^X policy is enforced
int fd = open("/proc/self/maps", O_RDONLY);
unsigned char buf2[1024];
while (1) {
int ret = read(fd, buf2, 1024);
if (ret <= 0) break;
write(1, buf2, ret);
}
close(fd);
}
$ gcc test.c -o test
$ ./test | grep rwx
7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)
[PM: subject line tweaks]
CVE-2024-47745
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cxgb4: Added NULL check for lookup_atid
The lookup_atid() function can return NULL if the ATID is
invalid or does not exist in the identifier table, which
could lead to dereferencing a null pointer without a
check in the `act_establish()` and `act_open_rpl()` functions.
Add a NULL check to prevent null pointer dereferencing.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-47749
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Vim is an open source, command line text editor. A use-after-free was found in Vim < 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2024-47814
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg
When receiving proposal msg in server, the field iparea_offset
and the field ipv6_prefixes_cnt in proposal msg are from the
remote client and can not be fully trusted. Especially the
field iparea_offset, once exceed the max value, there has the
chance to access wrong address, and crash may happen.
This patch checks iparea_offset and ipv6_prefixes_cnt before using them.
CVE-2024-49571
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tpm: Clean up TPM space after command failure
tpm_dev_transmit prepares the TPM space before attempting command
transmission. However if the command fails no rollback of this
preparation is done. This can result in transient handles being leaked
if the device is subsequently closed with no further commands performed.
Fix this by flushing the space in the event of command transmission
failure.
CVE-2024-49851
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption
The TPM event log table is a Linux specific construct, where the data
produced by the GetEventLog() boot service is cached in memory, and
passed on to the OS using an EFI configuration table.
The use of EFI_LOADER_DATA here results in the region being left
unreserved in the E820 memory map constructed by the EFI stub, and this
is the memory description that is passed on to the incoming kernel by
kexec, which is therefore unaware that the region should be reserved.
Even though the utility of the TPM2 event log after a kexec is
questionable, any corruption might send the parsing code off into the
weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
instead, which is always treated as reserved by the E820 conversion
logic.
CVE-2024-49858
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: sysfs: validate return type of _STR method
Only buffer objects are valid return values of _STR.
If something else is returned description_show() will access invalid
memory.
CVE-2024-49860
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix helper writes to read-only maps
Lonial found an issue that despite user- and BPF-side frozen BPF map
(like in case of .rodata), it was still possible to write into it from
a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
as arguments.
In check_func_arg() when the argument is as mentioned, the meta->raw_mode
is never set. Later, check_helper_mem_access(), under the case of
PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
subsequent call to check_map_access_type() and given the BPF map is
read-only it succeeds.
The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
when results are written into them as opposed to read out of them. The
latter indicates that it's okay to pass a pointer to uninitialized memory
as the memory is written to anyway.
However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
just with additional alignment requirement. So it is better to just get
rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
alignment given these helpers write directly into the args via *<ptr> = val.
The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).
MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
the buffer size a priori and therefore cannot blindly write *<ptr> = val.
CVE-2024-49861
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix a NULL pointer dereference when failed to start a new trasacntion
[BUG]
Syzbot reported a NULL pointer dereference with the following crash:
FAULT_INJECTION: forcing a failure.
start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676
prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642
relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678
...
BTRFS info (device loop0): balance: ended with status: -12
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]
RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926
Call Trace:
<TASK>
commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496
btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430
del_balance_item fs/btrfs/volumes.c:3678 [inline]
reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742
btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574
btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
[CAUSE]
The allocation failure happens at the start_transaction() inside
prepare_to_relocate(), and during the error handling we call
unset_reloc_control(), which makes fs_info->balance_ctl to be NULL.
Then we continue the error path cleanup in btrfs_balance() by calling
reset_balance_state() which will call del_balance_item() to fully delete
the balance item in the root tree.
However during the small window between set_reloc_contrl() and
unset_reloc_control(), we can have a subvolume tree update and created a
reloc_root for that subvolume.
Then we go into the final btrfs_commit_transaction() of
del_balance_item(), and into btrfs_update_reloc_root() inside
commit_fs_roots().
That function checks if fs_info->reloc_ctl is in the merge_reloc_tree
stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer
dereference.
[FIX]
Just add extra check on fs_info->reloc_ctl inside
btrfs_update_reloc_root(), before checking
fs_info->reloc_ctl->merge_reloc_tree.
That DEAD_RELOC_TREE handling is to prevent further modification to the
reloc tree during merge stage, but since there is no reloc_ctl at all,
we do not need to bother that.
CVE-2024-49868
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger
NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if
bh is NULL.
CVE-2024-49877
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: update orig_path in ext4_find_extent()
In ext4_find_extent(), if the path is not big enough, we free it and set
*orig_path to NULL. But after reallocating and successfully initializing
the path, we don't update *orig_path, in which case the caller gets a
valid path but a NULL ppath, and this may cause a NULL pointer dereference
or a path memory leak. For example:
ext4_split_extent
path = *ppath = 2000
ext4_find_extent
if (depth > path[0].p_maxdepth)
kfree(path = 2000);
*orig_path = path = NULL;
path = kcalloc() = 3000
ext4_split_extent_at(*ppath = NULL)
path = *ppath;
ex = path[depth].p_ext;
// NULL pointer dereference!
==================================================================
BUG: kernel NULL pointer dereference, address: 0000000000000010
CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847
RIP: 0010:ext4_split_extent_at+0x6d/0x560
Call Trace:
<TASK>
ext4_split_extent.isra.0+0xcb/0x1b0
ext4_ext_convert_to_initialized+0x168/0x6c0
ext4_ext_handle_unwritten_extents+0x325/0x4d0
ext4_ext_map_blocks+0x520/0xdb0
ext4_map_blocks+0x2b0/0x690
ext4_iomap_begin+0x20e/0x2c0
[...]
==================================================================
Therefore, *orig_path is updated when the extent lookup succeeds, so that
the caller can safely use path or *ppath.
CVE-2024-49881
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double brelse() the buffer of the extents path
In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
released, otherwise it may be released twice. An example of what triggers
this is as follows:
split2 map split1
|--------|-------|--------|
ext4_ext_map_blocks
ext4_ext_handle_unwritten_extents
ext4_split_convert_extents
// path->p_depth == 0
ext4_split_extent
// 1. do split1
ext4_split_extent_at
|ext4_ext_insert_extent
| ext4_ext_create_new_leaf
| ext4_ext_grow_indepth
| le16_add_cpu(&neh->eh_depth, 1)
| ext4_find_extent
| // return -ENOMEM
|// get error and try zeroout
|path = ext4_find_extent
| path->p_depth = 1
|ext4_ext_try_to_merge
| ext4_ext_try_to_merge_up
| path->p_depth = 0
| brelse(path[1].p_bh) ---> not set to NULL here
|// zeroout success
// 2. update path
ext4_find_extent
// 3. do split2
ext4_split_extent_at
ext4_ext_insert_extent
ext4_ext_create_new_leaf
ext4_ext_grow_indepth
le16_add_cpu(&neh->eh_depth, 1)
ext4_find_extent
path[0].p_bh = NULL;
path->p_depth = 1
read_extent_tree_block ---> return err
// path[1].p_bh is still the old value
ext4_free_ext_path
ext4_ext_drop_refs
// path->p_depth == 1
brelse(path[1].p_bh) ---> brelse a buffer twice
Finally got the following WARRNING when removing the buffer from lru:
============================================
VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90
CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716
RIP: 0010:__brelse+0x58/0x90
Call Trace:
<TASK>
__find_get_block+0x6e7/0x810
bdev_getblk+0x2b/0x480
__ext4_get_inode_loc+0x48a/0x1240
ext4_get_inode_loc+0xb2/0x150
ext4_reserve_inode_write+0xb7/0x230
__ext4_mark_inode_dirty+0x144/0x6a0
ext4_ext_insert_extent+0x9c8/0x3230
ext4_ext_map_blocks+0xf45/0x2dc0
ext4_map_blocks+0x724/0x1700
ext4_do_writepages+0x12d6/0x2a70
[...]
============================================
CVE-2024-49882
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: aovid use-after-free in ext4_ext_insert_extent()
As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is
reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and
cause UAF. Below is a sample trace with dummy values:
ext4_ext_insert_extent
path = *ppath = 2000
ext4_ext_create_new_leaf(ppath)
ext4_find_extent(ppath)
path = *ppath = 2000
if (depth > path[0].p_maxdepth)
kfree(path = 2000);
*ppath = path = NULL;
path = kcalloc() = 3000
*ppath = 3000;
return path;
/* here path is still 2000, UAF! */
eh = path[depth].p_hdr
==================================================================
BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330
Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179
CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866
Call Trace:
<TASK>
ext4_ext_insert_extent+0x26d4/0x3330
ext4_ext_map_blocks+0xe22/0x2d40
ext4_map_blocks+0x71e/0x1700
ext4_do_writepages+0x1290/0x2800
[...]
Allocated by task 179:
ext4_find_extent+0x81c/0x1f70
ext4_ext_map_blocks+0x146/0x2d40
ext4_map_blocks+0x71e/0x1700
ext4_do_writepages+0x1290/0x2800
ext4_writepages+0x26d/0x4e0
do_writepages+0x175/0x700
[...]
Freed by task 179:
kfree+0xcb/0x240
ext4_find_extent+0x7c0/0x1f70
ext4_ext_insert_extent+0xa26/0x3330
ext4_ext_map_blocks+0xe22/0x2d40
ext4_map_blocks+0x71e/0x1700
ext4_do_writepages+0x1290/0x2800
ext4_writepages+0x26d/0x4e0
do_writepages+0x175/0x700
[...]
==================================================================
So use *ppath to update the path to avoid the above problem.
CVE-2024-49883
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: ensure the fw_info is not null before using it
This resolves the dereference null return value warning
reported by Coverity.
CVE-2024-49890
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths
When the HBA is undergoing a reset or is handling an errata event, NULL ptr
dereference crashes may occur in routines such as
lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or
lpfc_abort_handler().
Add NULL ptr checks before dereferencing hdwq pointers that may have been
freed due to operations colliding with a reset or errata event handler.
CVE-2024-49891
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in degamma hardware format translation
Fixes index out of bounds issue in
`cm_helper_translate_curve_to_degamma_hw_format` function. The issue
could occur when the index 'i' exceeds the number of transfer function
points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds the function returns
false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
CVE-2024-49894
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check stream before comparing them
[WHAT & HOW]
amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is
necessary to check for null before dereferencing them.
This fixes 1 FORWARD_NULL issue reported by Coverity.
CVE-2024-49896
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs
There are some cases, such as the one uncovered by Commit 46d4efcccc68
("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")
where
msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);
is called on gpu->pdev == NULL, as the GPU device has not been fully
initialized yet.
Turns out that there's more than just the aforementioned path that
causes this to happen (e.g. the case when there's speedbin data in the
catalog, but opp-supported-hw is missing in DT).
Assigning msm_gpu->pdev earlier seems like the least painful solution
to this, therefore do so.
Patchwork: https://patchwork.freedesktop.org/patch/602742/
CVE-2024-49901
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before multiple uses
[WHAT & HOW]
Poniters, such as stream_enc and dc->bw_vbios, are null checked previously
in the same function, so Coverity warns "implies that stream_enc and
dc->bw_vbios might be null". They are used multiple times in the
subsequent code and need to be checked.
This fixes 10 FORWARD_NULL issues reported by Coverity.
CVE-2024-49920
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before used
[WHAT & HOW]
Poniters, such as dc->clk_mgr, are null checked previously in the same
function, so Coverity warns "implies that "dc->clk_mgr" might be null".
As a result, these pointers need to be checked when used again.
This fixes 10 FORWARD_NULL issues reported by Coverity.
CVE-2024-49921
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: avoid NULL pointer dereference
iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
pointer is not NULL.
It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
dereferencing the ieee80211_sta pointer.
If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
pointer.
Fix this by checking the sta pointer before retrieving the mvmsta
from it. If sta is not NULL, then mvmsta isn't either.
CVE-2024-49929
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: PAD: fix crash in exit_round_robin()
The kernel occasionally crashes in cpumask_clear_cpu(), which is called
within exit_round_robin(), because when executing clear_bit(nr, addr) with
nr set to 0xffffffff, the address calculation may cause misalignment within
the memory, leading to access to an invalid memory address.
----------
BUG: unable to handle kernel paging request at ffffffffe0740618
...
CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1
...
RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]
Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31
RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202
RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8
R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e
R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e
FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
? acpi_pad_add+0x120/0x120 [acpi_pad]
kthread+0x10b/0x130
? set_kthread_struct+0x50/0x50
ret_from_fork+0x1f/0x40
...
CR2: ffffffffe0740618
crash> dis -lr ffffffffc0726923
...
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114
0xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325
0xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80
0xffffffffc0726923 <power_saving_thread+787>: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <pad_busy_cpus_bits>
crash> px tsk_in_cpu[14]
$66 = 0xffffffff
crash> px 0xffffffffc072692c+0x19cf4
$99 = 0xffffffffc0740620
crash> sym 0xffffffffc0740620
ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]
crash> px pad_busy_cpus_bits[0]
$42 = 0xfffc0
----------
To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling
cpumask_clear_cpu() in exit_round_robin(), just as it is done in
round_robin_cpu().
[ rjw: Subject edit, avoid updates to the same value ]
CVE-2024-49935
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/xen-netback: prevent UAF in xenvif_flush_hash()
During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
kfree_rcu does not exist inside the rcu read critical section, so if
kfree_rcu is called when the rcu grace period ends during the iteration,
UAF occurs when accessing head->next after the entry becomes free.
Therefore, to solve this, you need to change it to list_for_each_entry_safe.
CVE-2024-49936
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit
Syzbot points out that skb_trim() has a sanity check on the existing length of
the skb, which can be uninitialised in some error paths. The intent here is
clearly just to reset the length to zero before resubmitting, so switch to
calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()
already contains a call to skb_reset_tail_pointer(), so remove the redundant
call.
The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar
usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.
CVE-2024-49938
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
l2tp: prevent possible tunnel refcount underflow
When a session is created, it sets a backpointer to its tunnel. When
the session refcount drops to 0, l2tp_session_free drops the tunnel
refcount if session->tunnel is non-NULL. However, session->tunnel is
set in l2tp_session_create, before the tunnel refcount is incremented
by l2tp_session_register, which leaves a small window where
session->tunnel is non-NULL when the tunnel refcount hasn't been
bumped.
Moving the assignment to l2tp_session_register is trivial but
l2tp_session_create calls l2tp_session_set_header_len which uses
session->tunnel to get the tunnel's encap. Add an encap arg to
l2tp_session_set_header_len to avoid using session->tunnel.
If l2tpv3 sessions have colliding IDs, it is possible for
l2tp_v3_session_get to race with l2tp_session_register and fetch a
session which doesn't yet have session->tunnel set. Add a check for
this case.
CVE-2024-49940
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start
In sctp_listen_start() invoked by sctp_inet_listen(), it should set the
sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.
Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse
is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will
be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash
is NULL.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617
Call Trace:
<TASK>
__sys_listen_socket net/socket.c:1883 [inline]
__sys_listen+0x1b7/0x230 net/socket.c:1894
__do_sys_listen net/socket.c:1902 [inline]
CVE-2024-49944
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/ncsi: Disable the ncsi work before freeing the associated structure
The work function can run after the ncsi device is freed, resulting
in use-after-free bugs or kernel panic.
CVE-2024-49945
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: avoid potential underflow in qdisc_pkt_len_init() with UFO
After commit 7c6d2ecbda83 ("net: be more gentle about silly gso
requests coming from user") virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.
Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count
transport header in UFO") while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :
IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.
When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb->len
Then the following sets gso_segs to 0 :
gso_segs = DIV_ROUND_UP(skb->len - hdr_len,
shinfo->gso_size);
Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/
qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;
This leads to the following crash in fq_codel [1]
qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.
This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.
[1]
[ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 70.724561] #PF: supervisor read access in kernel mode
[ 70.724561] #PF: error_code(0x0000) - not-present page
[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI
[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991
[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel
[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49
All code
========
0: 24 08 and $0x8,%al
2: 49 c1 e1 06 shl $0x6,%r9
6: 44 89 7c 24 18 mov %r15d,0x18(%rsp)
b: 45 31 ed xor %r13d,%r13d
e: 45 31 c0 xor %r8d,%r8d
11: 31 ff xor %edi,%edi
13: 89 44 24 14 mov %eax,0x14(%rsp)
17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9
1e: eb 04 jmp 0x24
20: 39 ca cmp %ecx,%edx
22: 73 37 jae 0x5b
24: 4d 8b 39 mov (%r9),%r15
27: 83 c7 01 add $0x1,%edi
2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction
2d: 49 89 11 mov %rdx,(%r9)
30: 41 8b 57 28 mov 0x28(%r15),%edx
34: 45 8b 5f 34 mov 0x34(%r15),%r11d
38: 49 c7 07 00 00 00 00 movq $0x0,(%r15)
3f: 49 rex.WB
Code starting with the faulting instruction
===========================================
0: 49 8b 17 mov (%r15),%rdx
3: 49 89 11 mov %rdx,(%r9)
6: 41 8b 57 28 mov 0x28(%r15),%edx
a: 45 8b 5f 34 mov 0x34(%r15),%r11d
e: 49 c7 07 00 00 00 00 movq $0x0,(%r15)
15: 49 rex.WB
[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202
[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000
[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000
[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58
[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000
[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000
[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C
---truncated---
CVE-2024-49949
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prevent nf_skb_duplicated corruption
syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write
per-cpu variable nf_skb_duplicated in an unsafe way [1].
Disabling preemption as hinted by the splat is not enough,
we have to disable soft interrupts as well.
[1]
BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316
caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49
nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30
expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
nf_hook+0x2c4/0x450 include/linux/netfilter.h:269
NF_HOOK_COND include/linux/netfilter.h:302 [inline]
ip_output+0x185/0x230 net/ipv4/ip_output.c:433
ip_local_out net/ipv4/ip_output.c:129 [inline]
ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495
udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981
udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x1a6/0x270 net/socket.c:745
____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
___sys_sendmsg net/socket.c:2651 [inline]
__sys_sendmmsg+0x3b2/0x740 net/socket.c:2737
__do_sys_sendmmsg net/socket.c:2766 [inline]
__se_sys_sendmmsg net/socket.c:2763 [inline]
__x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4ce4f7def9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9
RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006
RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
</TASK>
CVE-2024-49952
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix null-ptr-deref when journal load failed.
During the mounting process, if journal_reset() fails because of too short
journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer.
Subsequently, ocfs2_journal_shutdown() calls
jbd2_journal_flush()->jbd2_cleanup_journal_tail()->
__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()
->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer
dereference error.
To resolve this issue, we should check the JBD2_LOADED flag to ensure the
journal was properly loaded. Additionally, use journal instead of
osb->journal directly to simplify the code.
CVE-2024-49957
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: reserve space for inline xattr before attaching reflink tree
One of our customers reported a crash and a corrupted ocfs2 filesystem.
The crash was due to the detection of corruption. Upon troubleshooting,
the fsck -fn output showed the below corruption
[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
but fsck believes the largest valid value is 227. Clamp the next record value? n
The stat output from the debugfs.ocfs2 showed the following corruption
where the "Next Free Rec:" had overshot the "Count:" in the root metadata
block.
Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856)
FS Generation: 904309833 (0x35e6ac49)
CRC32: 00000000 ECC: 0000
Type: Regular Attr: 0x0 Flags: Valid
Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
Extended Attributes Block: 0 Extended Attributes Inline Size: 256
User: 0 (root) Group: 0 (root) Size: 281320357888
Links: 1 Clusters: 141738
ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024
atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024
mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024
dtime: 0x0 -- Wed Dec 31 17:00:00 1969
Refcount Block: 2777346
Last Extblk: 2886943 Orphan Slot: 0
Sub Alloc Slot: 0 Sub Alloc Bit: 14
Tree Depth: 1 Count: 227 Next Free Rec: 230
## Offset Clusters Block#
0 0 2310 2776351
1 2310 2139 2777375
2 4449 1221 2778399
3 5670 731 2779423
4 6401 566 2780447
....... .... .......
....... .... .......
The issue was in the reflink workfow while reserving space for inline
xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the
time this function is called the reflink tree is already recreated at the
destination inode from the source inode. At this point, this function
reserves space for inline xattrs at the destination inode without even
checking if there is space at the root metadata block. It simply reduces
the l_count from 243 to 227 thereby making space of 256 bytes for inline
xattr whereas the inode already has extents beyond this index (in this
case up to 230), thereby causing corruption.
The fix for this is to reserve space for inline metadata at the destination
inode before the reflink tree gets recreated. The customer has verified the
fix.
CVE-2024-49958
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
to recover some journal space. But if an error occurs while executing
jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
space right away, we try other branches, and if j_committing_transaction
is NULL (i.e., the tid is 0), we will get the following complain:
============================================
JBD2: I/O error when updating journal superblock for sdd-8.
__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
__jbd2_log_wait_for_space: no way to get more journal space in sdd-8
------------[ cut here ]------------
WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
Modules linked in:
CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
Call Trace:
<TASK>
add_transaction_credits+0x5d1/0x5e0
start_this_handle+0x1ef/0x6a0
jbd2__journal_start+0x18b/0x340
ext4_dirty_inode+0x5d/0xb0
__mark_inode_dirty+0xe4/0x5d0
generic_update_time+0x60/0x70
[...]
============================================
So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
clean up at the moment, continue to try to reclaim free space in other ways.
Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
when updating journal superblock fails") to make jbd2_cleanup_journal_tail
return the correct error code.
CVE-2024-49959
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()
ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0
ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause
NULL pointer dereference later.
[ rjw: Subject and changelog edits ]
CVE-2024-49962
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: remove unreasonable unlock in ocfs2_read_blocks
Patch series "Misc fixes for ocfs2_read_blocks", v5.
This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix
the issue reported by syzbot, which detects bad unlock balance in
ocfs2_read_blocks(). The second patch fixes an issue reported by Heming
Zhao when reviewing above fix.
This patch (of 2):
There was a lock release before exiting, so remove the unreasonable unlock.
CVE-2024-49965
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: cancel dqi_sync_work before freeing oinfo
ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the
end, if error occurs after successfully reading global quota, it will
trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:
ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c
This reports that there is an active delayed work when freeing oinfo in
error handling, so cancel dqi_sync_work first. BTW, return status instead
of -1 when .read_file_info fails.
CVE-2024-49966
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-49967
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer
Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,
otherwise amdgpu_bo_unref clear the local variable, the original pointer
not set to NULL, this could cause use-after-free bug.
CVE-2024-49991
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
block: fix integer overflow in BLKSECDISCARD
I independently rediscovered
commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
block: fix overflow in blk_ioctl_discard()
but for secure erase.
Same problem:
uint64_t r[2] = {512, 18446744073709551104ULL};
ioctl(fd, BLKSECDISCARD, r);
will enter near infinite loop inside blkdev_issue_secure_erase():
a.out: attempt to access beyond end of device
loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048
bio_check_eod: 3286214 callbacks suppressed
CVE-2024-49994
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-49995
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix buffer overflow when parsing NFS reparse points
ReparseDataLength is sum of the InodeType size and DataBuffer size.
So to get DataBuffer size it is needed to subtract InodeType's size from
ReparseDataLength.
Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer
at position after the end of the buffer because it does not subtract
InodeType size from the length. Fix this problem and correctly subtract
variable len.
Member InodeType is present only when reparse buffer is large enough. Check
for ReparseDataLength before accessing InodeType to prevent another invalid
memory access.
Major and minor rdev values are present also only when reparse buffer is
large enough. Check for reparse buffer size before calling reparse_mkdev().
CVE-2024-49996
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix i_data_sem unlock order in ext4_ind_migrate()
Fuzzing reports a possible deadlock in jbd2_log_wait_commit.
This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require
synchronous updates because the file descriptor is opened with O_SYNC.
This can lead to the jbd2_journal_stop() function calling
jbd2_might_wait_for_commit(), potentially causing a deadlock if the
EXT4_IOC_MIGRATE call races with a write(2) system call.
This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this
case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the
jbd2_journal_stop function while i_data_sem is locked. This triggers
lockdep because the jbd2_journal_start function might also lock the same
jbd2_handle simultaneously.
Found by Linux Verification Center (linuxtesting.org) with syzkaller.
Rule: add
CVE-2024-50006
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: asihpi: Fix potential OOB array access
ASIHPI driver stores some values in the static array upon a response
from the driver, and its index depends on the firmware. We shouldn't
trust it blindly.
This patch adds a sanity check of the array index to fit in the array
size.
CVE-2024-50007
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: Fix an unsafe loop on the list
The kernel may crash when deleting a genetlink family if there are still
listeners for that family:
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0
LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0
Call Trace:
__netlink_clear_multicast_users+0x74/0xc0
genl_unregister_family+0xd4/0x2d0
Change the unsafe loop on the list to a safe one, because inside the
loop there is an element removal from this list.
CVE-2024-50024
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
slip: make slhc_remember() more robust against malicious packets
syzbot found that slhc_remember() was missing checks against
malicious packets [1].
slhc_remember() only checked the size of the packet was at least 20,
which is not good enough.
We need to make sure the packet includes the IPv4 and TCP header
that are supposed to be carried.
Add iph and th pointers to make the code more readable.
[1]
BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455
ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]
ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212
ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327
pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
__release_sock+0x1da/0x330 net/core/sock.c:3072
release_sock+0x6b/0x250 net/core/sock.c:3626
pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4091 [inline]
slab_alloc_node mm/slub.c:4134 [inline]
kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
__alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
alloc_skb include/linux/skbuff.h:1322 [inline]
sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
CVE-2024-50033
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix ppp_async_encode() illegal access
syzbot reported an issue in ppp_async_encode() [1]
In this case, pppoe_sendmsg() is called with a zero size.
Then ppp_async_encode() is called with an empty skb.
BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634
ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]
ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304
pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
__release_sock+0x1da/0x330 net/core/sock.c:3072
release_sock+0x6b/0x250 net/core/sock.c:3626
pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4092 [inline]
slab_alloc_node mm/slub.c:4135 [inline]
kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
__alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
alloc_skb include/linux/skbuff.h:1322 [inline]
sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:744
____sys_sendmsg+0x903/0xb60 net/socket.c:2602
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
__sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
__do_sys_sendmmsg net/socket.c:2771 [inline]
__se_sys_sendmmsg net/socket.c:2768 [inline]
__x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
CVE-2024-50035
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: avoid NFPROTO_UNSPEC where needed
syzbot managed to call xt_cluster match via ebtables:
WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780
[..]
ebt_do_table+0x174b/0x2a40
Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet
processing. As this is only useful to restrict locally terminating
TCP/UDP traffic, register this for ipv4 and ipv6 family only.
Pablo points out that this is a general issue, direct users of the
set/getsockopt interface can call into targets/matches that were only
intended for use with ip(6)tables.
Check all UNSPEC matches and targets for similar issues:
- matches and targets are fine except if they assume skb_network_header()
is valid -- this is only true when called from inet layer: ip(6) stack
pulls the ip/ipv6 header into linear data area.
- targets that return XT_CONTINUE or other xtables verdicts must be
restricted too, they are incompatbile with the ebtables traverser, e.g.
EBT_CONTINUE is a completely different value than XT_CONTINUE.
Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as
they are provided for use by ip(6)tables.
The MARK target is also used by arptables, so register for NFPROTO_ARP too.
While at it, bail out if connbytes fails to enable the corresponding
conntrack family.
This change passes the selftests in iptables.git.
CVE-2024-50038
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: accept TCA_STAB only for root qdisc
Most qdiscs maintain their backlog using qdisc_pkt_len(skb)
on the assumption it is invariant between the enqueue()
and dequeue() handlers.
Unfortunately syzbot can crash a host rather easily using
a TBF + SFQ combination, with an STAB on SFQ [1]
We can't support TCA_STAB on arbitrary level, this would
require to maintain per-qdisc storage.
[1]
[ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 88.798611] #PF: supervisor read access in kernel mode
[ 88.799014] #PF: error_code(0x0000) - not-present page
[ 88.799506] PGD 0 P4D 0
[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI
[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117
[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00
All code
========
0: 0f b7 50 12 movzwl 0x12(%rax),%edx
4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax
b: 00
c: 48 89 d6 mov %rdx,%rsi
f: 48 29 d0 sub %rdx,%rax
12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx
19: 48 c1 e0 03 shl $0x3,%rax
1d: 48 01 c2 add %rax,%rdx
20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx)
25: 7e c0 jle 0xffffffffffffffe7
27: 48 8b 3a mov (%rdx),%rdi
2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction
2d: 4c 89 02 mov %r8,(%rdx)
30: 49 89 50 08 mov %rdx,0x8(%r8)
34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi)
3b: 00
3c: 48 rex.W
3d: c7 .byte 0xc7
3e: 07 (bad)
...
Code starting with the faulting instruction
===========================================
0: 4c 8b 07 mov (%rdi),%r8
3: 4c 89 02 mov %r8,(%rdx)
6: 49 89 50 08 mov %rdx,0x8(%r8)
a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi)
11: 00
12: 48 rex.W
13: c7 .byte 0xc7
14: 07 (bad)
...
[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206
[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800
[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000
[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f
[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140
[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac
[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000
[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0
[ 88.808165] Call Trace:
[ 88.808459] <TASK>
[ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)
[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)
[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)
[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq
[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g
---truncated---
CVE-2024-50039
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:
======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73
but task is already holding lock:
ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
CVE-2024-50044
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: br_netfilter: fix panic with metadata_dst skb
Fix a kernel panic in the br_netfilter module when sending untagged
traffic via a VxLAN device.
This happens during the check for fragmentation in br_nf_dev_queue_xmit.
It is dependent on:
1) the br_netfilter module being loaded;
2) net.bridge.bridge-nf-call-iptables set to 1;
3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
4) untagged frames with size higher than the VxLAN MTU forwarded/flooded
When forwarding the untagged packet to the VxLAN bridge port, before
the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and
changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type
of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.
Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check
for frames that needs to be fragmented: frames with higher MTU than the
VxLAN device end up calling br_nf_ip_fragment, which in turns call
ip_skb_dst_mtu.
The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
with valid dst->dev, thus the crash.
This case was never supported in the first place, so drop the packet
instead.
PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
[ 176.291791] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000110
[ 176.292101] Mem abort info:
[ 176.292184] ESR = 0x0000000096000004
[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits
[ 176.292530] SET = 0, FnV = 0
[ 176.292709] EA = 0, S1PTW = 0
[ 176.292862] FSC = 0x04: level 0 translation fault
[ 176.293013] Data abort info:
[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
[ 176.294166] [0000000000000110] pgd=0000000000000000,
p4d=0000000000000000
[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
br_netfilter bridge stp llc ipv6 crct10dif_ce
[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
6.8.0-rc3-g5b3fbd61b9d1 #2
[ 176.296314] Hardware name: linux,dummy-virt (DT)
[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
[ 176.297636] sp : ffff800080003630
[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
ffff6828c49ad9f8
[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
00000000000003e8
[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
ffff6828c3b16d28
[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
0000000000000014
[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
0000000095744632
[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
ffffb7e137926a70
[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
0000000000000000
[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
f20e0100bebafeca
[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
0000000000000000
[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
ffff6828c7f918f0
[ 176.300889] Call trace:
[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
[ 176.301703] nf_hook_slow+0x48/0x124
[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge]
[ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter]
[ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
[ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter]
[ 176.303359] nf_hook_slow+0x48/0x124
[ 176.303
---truncated---
CVE-2024-50045
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in async decryption
Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.
Reproducer:
# mount.cifs -o ...,seal,esize=1 //srv/share /mnt
# dd if=/mnt/largefile of=/dev/null
...
[ 194.196391] ==================================================================
[ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
[ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
[ 194.197707]
[ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43
[ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
[ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
[ 194.200032] Call Trace:
[ 194.200191] <TASK>
[ 194.200327] dump_stack_lvl+0x4e/0x70
[ 194.200558] ? gf128mul_4k_lle+0xc1/0x110
[ 194.200809] print_report+0x174/0x505
[ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 194.201352] ? srso_return_thunk+0x5/0x5f
[ 194.201604] ? __virt_addr_valid+0xdf/0x1c0
[ 194.201868] ? gf128mul_4k_lle+0xc1/0x110
[ 194.202128] kasan_report+0xc8/0x150
[ 194.202361] ? gf128mul_4k_lle+0xc1/0x110
[ 194.202616] gf128mul_4k_lle+0xc1/0x110
[ 194.202863] ghash_update+0x184/0x210
[ 194.203103] shash_ahash_update+0x184/0x2a0
[ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10
[ 194.203651] ? srso_return_thunk+0x5/0x5f
[ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340
[ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140
[ 194.204434] crypt_message+0xec1/0x10a0 [cifs]
[ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs]
[ 194.208507] ? srso_return_thunk+0x5/0x5f
[ 194.209205] ? srso_return_thunk+0x5/0x5f
[ 194.209925] ? srso_return_thunk+0x5/0x5f
[ 194.210443] ? srso_return_thunk+0x5/0x5f
[ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs]
[ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
[ 194.214670] ? srso_return_thunk+0x5/0x5f
[ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs]
This is because TFM is being used in parallel.
Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).
Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.
CVE-2024-50047
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
driver core: bus: Fix double free in driver API bus_register()
For bus_register(), any error which happens after kset_register() will
cause that @priv are freed twice, fixed by setting @priv with NULL after
the first free.
CVE-2024-50055
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: protect uart_port_dtr_rts() in uart_shutdown() too
Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part
3) added few uport == NULL checks. It added one to uart_shutdown(), so
the commit assumes, uport can be NULL in there. But right after that
protection, there is an unprotected "uart_port_dtr_rts(uport, false);"
call. That is invoked only if HUPCL is set, so I assume that is the
reason why we do not see lots of these reports.
Or it cannot be NULL at this point at all for some reason :P.
Until the above is investigated, stay on the safe side and move this
dereference to the if too.
I got this inconsistency from Coverity under CID 1585130. Thanks.
CVE-2024-50058
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
parport: Proper fix for array out-of-bounds access
The recent fix for array out-of-bounds accesses replaced sprintf()
calls blindly with snprintf(). However, since snprintf() returns the
would-be-printed size, not the actually output size, the length
calculation can still go over the given limit.
Use scnprintf() instead of snprintf(), which returns the actually
output letters, for addressing the potential out-of-bounds access
properly.
CVE-2024-50074
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mad: Improve handling of timed out WRs of mad agent
Current timeout handler of mad agent acquires/releases mad_agent_priv
lock for every timed out WRs. This causes heavy locking contention
when higher no. of WRs are to be handled inside timeout handler.
This leads to softlockup with below trace in some use cases where
rdma-cm path is used to establish connection between peer nodes
Trace:
-----
BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]
CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE
------- --- 5.14.0-427.13.1.el9_4.x86_64 #1
Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019
Workqueue: ib_mad1 timeout_sends [ib_core]
RIP: 0010:__do_softirq+0x78/0x2ac
RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246
RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f
RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b
RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000
R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040
FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<IRQ>
? show_trace_log_lvl+0x1c4/0x2df
? show_trace_log_lvl+0x1c4/0x2df
? __irq_exit_rcu+0xa1/0xc0
? watchdog_timer_fn+0x1b2/0x210
? __pfx_watchdog_timer_fn+0x10/0x10
? __hrtimer_run_queues+0x127/0x2c0
? hrtimer_interrupt+0xfc/0x210
? __sysvec_apic_timer_interrupt+0x5c/0x110
? sysvec_apic_timer_interrupt+0x37/0x90
? asm_sysvec_apic_timer_interrupt+0x16/0x20
? __do_softirq+0x78/0x2ac
? __do_softirq+0x60/0x2ac
__irq_exit_rcu+0xa1/0xc0
sysvec_call_function_single+0x72/0x90
</IRQ>
<TASK>
asm_sysvec_call_function_single+0x16/0x20
RIP: 0010:_raw_spin_unlock_irq+0x14/0x30
RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247
RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800
RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c
RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538
R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c
cm_process_send_error+0x122/0x1d0 [ib_cm]
timeout_sends+0x1dd/0x270 [ib_core]
process_one_work+0x1e2/0x3b0
? __pfx_worker_thread+0x10/0x10
worker_thread+0x50/0x3a0
? __pfx_worker_thread+0x10/0x10
kthread+0xdd/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x29/0x50
</TASK>
Simplified timeout handler by creating local list of timed out WRs
and invoke send handler post creating the list. The new method acquires/
releases lock once to fetch the list and hence helps to reduce locking
contetiong when processing higher no. of WRs
CVE-2024-50095
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Remove broken LDR (literal) uprobe support
The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
unsafe to use for uprobes. Both functions were originally written for
use with kprobes, and access memory with plain C accesses. When uprobes
was added, these were reused unmodified even though they cannot safely
access user memory.
There are three key problems:
1) The plain C accesses do not have corresponding extable entries, and
thus if they encounter a fault the kernel will treat these as
unintentional accesses to user memory, resulting in a BUG() which
will kill the kernel thread, and likely lead to further issues (e.g.
lockup or panic()).
2) The plain C accesses are subject to HW PAN and SW PAN, and so when
either is in use, any attempt to simulate an access to user memory
will fault. Thus neither simulate_ldr_literal() nor
simulate_ldrsw_literal() can do anything useful when simulating a
user instruction on any system with HW PAN or SW PAN.
3) The plain C accesses are privileged, as they run in kernel context,
and in practice can access a small range of kernel virtual addresses.
The instructions they simulate have a range of +/-1MiB, and since the
simulated instructions must itself be a user instructions in the
TTBR0 address range, these can address the final 1MiB of the TTBR1
acddress range by wrapping downwards from an address in the first
1MiB of the TTBR0 address range.
In contemporary kernels the last 8MiB of TTBR1 address range is
reserved, and accesses to this will always fault, meaning this is no
worse than (1).
Historically, it was theoretically possible for the linear map or
vmemmap to spill into the final 8MiB of the TTBR1 address range, but
in practice this is extremely unlikely to occur as this would
require either:
* Having enough physical memory to fill the entire linear map all the
way to the final 1MiB of the TTBR1 address range.
* Getting unlucky with KASLR randomization of the linear map such
that the populated region happens to overlap with the last 1MiB of
the TTBR address range.
... and in either case if we were to spill into the final page there
would be larger problems as the final page would alias with error
pointers.
Practically speaking, (1) and (2) are the big issues. Given there have
been no reports of problems since the broken code was introduced, it
appears that no-one is relying on probing these instructions with
uprobes.
Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
(literal), limiting the use of simulate_ldr_literal() and
simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
(literal) and LDRSW (literal) will be rejected as
arm_probe_decode_insn() will return INSN_REJECTED. In future we can
consider introducing working uprobes support for these instructions, but
this will require more significant work.
CVE-2024-50099
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix race between laundromat and free_stateid
There is a race between laundromat handling of revoked delegations
and a client sending free_stateid operation. Laundromat thread
finds that delegation has expired and needs to be revoked so it
marks the delegation stid revoked and it puts it on a reaper list
but then it unlock the state lock and the actual delegation revocation
happens without the lock. Once the stid is marked revoked a racing
free_stateid processing thread does the following (1) it calls
list_del_init() which removes it from the reaper list and (2) frees
the delegation stid structure. The laundromat thread ends up not
calling the revoke_delegation() function for this particular delegation
but that means it will no release the lock lease that exists on
the file.
Now, a new open for this file comes in and ends up finding that
lease list isn't empty and calls nfsd_breaker_owns_lease() which ends
up trying to derefence a freed delegation stateid. Leading to the
followint use-after-free KASAN warning:
kernel: ==================================================================
kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205
kernel:
kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9
kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024
kernel: Call trace:
kernel: dump_backtrace+0x98/0x120
kernel: show_stack+0x1c/0x30
kernel: dump_stack_lvl+0x80/0xe8
kernel: print_address_description.constprop.0+0x84/0x390
kernel: print_report+0xa4/0x268
kernel: kasan_report+0xb4/0xf8
kernel: __asan_report_load8_noabort+0x1c/0x28
kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]
kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]
kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]
kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]
kernel: nfsd4_open+0xa08/0xe80 [nfsd]
kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]
kernel: nfsd_dispatch+0x22c/0x718 [nfsd]
kernel: svc_process_common+0x8e8/0x1960 [sunrpc]
kernel: svc_process+0x3d4/0x7e0 [sunrpc]
kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]
kernel: svc_recv+0x2cc/0x6a8 [sunrpc]
kernel: nfsd+0x270/0x400 [nfsd]
kernel: kthread+0x288/0x310
kernel: ret_from_fork+0x10/0x20
This patch proposes a fixed that's based on adding 2 new additional
stid's sc_status values that help coordinate between the laundromat
and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).
First to make sure, that once the stid is marked revoked, it is not
removed by the nfsd4_free_stateid(), the laundromat take a reference
on the stateid. Then, coordinating whether the stid has been put
on the cl_revoked list or we are processing FREE_STATEID and need to
make sure to remove it from the list, each check that state and act
accordingly. If laundromat has added to the cl_revoke list before
the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove
it from the list. If nfsd4_free_stateid() finds that operations arrived
before laundromat has placed it on cl_revoke list, it marks the state
freed and then laundromat will no longer add it to the list.
Also, for nfsd4_delegreturn() when looking for the specified stid,
we need to access stid that are marked removed or freeable, it means
the laundromat has started processing it but hasn't finished and this
delegreturn needs to return nfserr_deleg_revoked and not
nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the
lack of it will leave this stid on the cl_revoked list indefinitely.
CVE-2024-50106
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Guard against bad data for ATIF ACPI method
If a BIOS provides bad data in response to an ATIF method call
this causes a NULL pointer dereference in the caller.
```
? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))
? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)
? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))
? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))
? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)
? exc_page_fault (arch/x86/mm/fault.c:1542)
? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu
```
It has been encountered on at least one system, so guard for it.
(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)
CVE-2024-50117
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix UAF on sco_sock_timeout
conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock
so this checks if the conn->sk is still valid by checking if it part of
sco_sk_list.
CVE-2024-50125
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix race condition between reset and nvme_dev_disable()
nvme_dev_disable() modifies the dev->online_queues field, therefore
nvme_pci_update_nr_queues() should avoid racing against it, otherwise
we could end up passing invalid values to blk_mq_update_nr_hw_queues().
WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347
pci_irq_get_affinity+0x187/0x210
Workqueue: nvme-reset-wq nvme_reset_work [nvme]
RIP: 0010:pci_irq_get_affinity+0x187/0x210
Call Trace:
<TASK>
? blk_mq_pci_map_queues+0x87/0x3c0
? pci_irq_get_affinity+0x187/0x210
blk_mq_pci_map_queues+0x87/0x3c0
nvme_pci_map_queues+0x189/0x460 [nvme]
blk_mq_update_nr_hw_queues+0x2a/0x40
nvme_reset_work+0x1be/0x2a0 [nvme]
Fix the bug by locking the shutdown_lock mutex before using
dev->online_queues. Give up if nvme_dev_disable() is running or if
it has been executed already.
CVE-2024-50135
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: fix wild-memory-access in proto_unregister
There's issue as follows:
KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W
RIP: 0010:proto_unregister+0xee/0x400
Call Trace:
<TASK>
__do_sys_delete_module+0x318/0x580
do_syscall_64+0xc1/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
will cleanup all resource. Then when remove bnep module will call
bnep_sock_cleanup() to cleanup sock's resource.
To solve above issue just return bnep_sock_init()'s return value in
bnep_exit().
CVE-2024-50148
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmode should keep reference to parent
The altmode device release refers to its parent device, but without keeping
a reference to it.
When registering the altmode, get a reference to the parent and put it in
the release function.
Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues
like this:
[ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)
[ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)
[ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)
[ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)
[ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)
[ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)
[ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)
[ 46.612867] ==================================================================
[ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129
[ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48
[ 46.614538]
[ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535
[ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[ 46.616042] Workqueue: events kobject_delayed_cleanup
[ 46.616446] Call Trace:
[ 46.616648] <TASK>
[ 46.616820] dump_stack_lvl+0x5b/0x7c
[ 46.617112] ? typec_altmode_release+0x38/0x129
[ 46.617470] print_report+0x14c/0x49e
[ 46.617769] ? rcu_read_unlock_sched+0x56/0x69
[ 46.618117] ? __virt_addr_valid+0x19a/0x1ab
[ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d
[ 46.618807] ? typec_altmode_release+0x38/0x129
[ 46.619161] kasan_report+0x8d/0xb4
[ 46.619447] ? typec_altmode_release+0x38/0x129
[ 46.619809] ? process_scheduled_works+0x3cb/0x85f
[ 46.620185] typec_altmode_release+0x38/0x129
[ 46.620537] ? process_scheduled_works+0x3cb/0x85f
[ 46.620907] device_release+0xaf/0xf2
[ 46.621206] kobject_delayed_cleanup+0x13b/0x17a
[ 46.621584] process_scheduled_works+0x4f6/0x85f
[ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10
[ 46.622353] ? hlock_class+0x31/0x9a
[ 46.622647] ? lock_acquired+0x361/0x3c3
[ 46.622956] ? move_linked_works+0x46/0x7d
[ 46.623277] worker_thread+0x1ce/0x291
[ 46.623582] ? __kthread_parkme+0xc8/0xdf
[ 46.623900] ? __pfx_worker_thread+0x10/0x10
[ 46.624236] kthread+0x17e/0x190
[ 46.624501] ? kthread+0xfb/0x190
[ 46.624756] ? __pfx_kthread+0x10/0x10
[ 46.625015] ret_from_fork+0x20/0x40
[ 46.625268] ? __pfx_kthread+0x10/0x10
[ 46.625532] ret_from_fork_asm+0x1a/0x30
[ 46.625805] </TASK>
[ 46.625953]
[ 46.626056] Allocated by task 678:
[ 46.626287] kasan_save_stack+0x24/0x44
[ 46.626555] kasan_save_track+0x14/0x2d
[ 46.626811] __kasan_kmalloc+0x3f/0x4d
[ 46.627049] __kmalloc_noprof+0x1bf/0x1f0
[ 46.627362] typec_register_port+0x23/0x491
[ 46.627698] cros_typec_probe+0x634/0xbb6
[ 46.628026] platform_probe+0x47/0x8c
[ 46.628311] really_probe+0x20a/0x47d
[ 46.628605] device_driver_attach+0x39/0x72
[ 46.628940] bind_store+0x87/0xd7
[ 46.629213] kernfs_fop_write_iter+0x1aa/0x218
[ 46.629574] vfs_write+0x1d6/0x29b
[ 46.629856] ksys_write+0xcd/0x13b
[ 46.630128] do_syscall_64+0xd4/0x139
[ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 46.630820]
[ 46.630946] Freed by task 48:
[ 46.631182] kasan_save_stack+0x24/0x44
[ 46.631493] kasan_save_track+0x14/0x2d
[ 46.631799] kasan_save_free_info+0x3f/0x4d
[ 46.632144] __kasan_slab_free+0x37/0x45
[ 46.632474]
---truncated---
CVE-2024-50150
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().
"""
We are seeing a use-after-free from a bpf prog attached to
trace_tcp_retransmit_synack. The program passes the req->sk to the
bpf_sk_storage_get_tracing kernel helper which does check for null
before using it.
"""
The commit 83fccfc3940c ("inet: fix potential deadlock in
reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
small race window.
Before the timer is called, expire_timers() calls detach_timer(timer, true)
to clear timer->entry.pprev and marks it as not pending.
If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
continue running and send multiple SYN+ACKs until it expires.
The reported UAF could happen if req->sk is close()d earlier than the timer
expiration, which is 63s by default.
The scenario would be
1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
but del_timer_sync() is missed
2. reqsk timer is executed and scheduled again
3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
reqsk timer still has another one, and inet_csk_accept() does not
clear req->sk for non-TFO sockets
4. sk is close()d
5. reqsk timer is executed again, and BPF touches req->sk
Let's not use timer_pending() by passing the caller context to
__inet_csk_reqsk_queue_drop().
Note that reqsk timer is pinned, so the issue does not happen in most
use cases. [1]
[0]
BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0
Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
bpf_sk_storage_get_tracing+0x2e/0x1b0
bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
bpf_trace_run2+0x4c/0xc0
tcp_rtx_synack+0xf9/0x100
reqsk_timer_handler+0xda/0x3d0
run_timer_softirq+0x292/0x8a0
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
intel_idle_irq+0x5a/0xa0
cpuidle_enter_state+0x94/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6
allocated by task 0 on cpu 9 at 260507.901592s:
sk_prot_alloc+0x35/0x140
sk_clone_lock+0x1f/0x3f0
inet_csk_clone_lock+0x15/0x160
tcp_create_openreq_child+0x1f/0x410
tcp_v6_syn_recv_sock+0x1da/0x700
tcp_check_req+0x1fb/0x510
tcp_v6_rcv+0x98b/0x1420
ipv6_list_rcv+0x2258/0x26e0
napi_complete_done+0x5b1/0x2990
mlx5e_napi_poll+0x2ae/0x8d0
net_rx_action+0x13e/0x590
irq_exit_rcu+0xf5/0x320
common_interrupt+0x80/0x90
asm_common_interrupt+0x22/0x40
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
freed by task 0 on cpu 9 at 260507.927527s:
rcu_core_si+0x4ff/0xf10
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb
CVE-2024-50154
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
be2net: fix potential memory leak in be_xmit()
The be_xmit() returns NETDEV_TX_OK without freeing skb
in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.
CVE-2024-50167
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: systemport: fix potential memory leak in bcm_sysport_xmit()
The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb
in case of dma_map_single() fails, add dev_kfree_skb() to fix it.
CVE-2024-50171
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ceph: remove the incorrect Fw reference check when dirtying pages
When doing the direct-io reads it will also try to mark pages dirty,
but for the read path it won't hold the Fw caps and there is case
will it get the Fw reference.
CVE-2024-50179
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance
Deleting an NPIV instance requires all fabric ndlps to be released before
an NPIV's resources can be torn down. Failure to release fabric ndlps
beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID
to complete synchronously with usage of wait_queue.
CVE-2024-50183
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Stop the active perfmon before being destroyed
Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4->active_perfmon`) is still
retained.
If we open a new file descriptor and submit a few jobs with performance
monitors, the driver will attempt to stop the active performance monitor
using the stale pointer in `vc4->active_perfmon`. However, this pointer
is no longer valid because the previous process has already terminated,
and all performance monitors associated with it have been destroyed and
freed.
To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.
CVE-2024-50187
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Fix uprobes for big-endian kernels
The arm64 uprobes code is broken for big-endian kernels as it doesn't
convert the in-memory instruction encoding (which is always
little-endian) into the kernel's native endianness before analyzing and
simulating instructions. This may result in a few distinct problems:
* The kernel may may erroneously reject probing an instruction which can
safely be probed.
* The kernel may erroneously erroneously permit stepping an
instruction out-of-line when that instruction cannot be stepped
out-of-line safely.
* The kernel may erroneously simulate instruction incorrectly dur to
interpretting the byte-swapped encoding.
The endianness mismatch isn't caught by the compiler or sparse because:
* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so
the compiler and sparse have no idea these contain a little-endian
32-bit value. The core uprobes code populates these with a memcpy()
which similarly does not handle endianness.
* While the uprobe_opcode_t type is an alias for __le32, both
arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]
to the similarly-named probe_opcode_t, which is an alias for u32.
Hence there is no endianness conversion warning.
Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and
adding the appropriate __le32_to_cpu() conversions prior to consuming
the instruction encoding. The core uprobes copies these fields as opaque
ranges of bytes, and so is unaffected by this change.
At the same time, remove MAX_UINSN_BYTES and consistently use
AARCH64_INSN_SIZE for clarity.
Tested with the following:
| #include <stdio.h>
| #include <stdbool.h>
|
| #define noinline __attribute__((noinline))
|
| static noinline void *adrp_self(void)
| {
| void *addr;
|
| asm volatile(
| " adrp %x0, adrp_self\n"
| " add %x0, %x0, :lo12:adrp_self\n"
| : "=r" (addr));
| }
|
|
| int main(int argc, char *argv)
| {
| void *ptr = adrp_self();
| bool equal = (ptr == adrp_self);
|
| printf("adrp_self => %p\n"
| "adrp_self() => %p\n"
| "%s\n",
| adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");
|
| return 0;
| }
.... where the adrp_self() function was compiled to:
| 00000000004007e0 <adrp_self>:
| 4007e0: 90000000 adrp x0, 400000 <__ehdr_start>
| 4007e4: 911f8000 add x0, x0, #0x7e0
| 4007e8: d65f03c0 ret
Before this patch, the ADRP is not recognized, and is assumed to be
steppable, resulting in corruption of the result:
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0x4007e0
| EQUAL
| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events
| # echo 1 > /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0xffffffffff7e0
| NOT EQUAL
After this patch, the ADRP is correctly recognized and simulated:
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0x4007e0
| EQUAL
| #
| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events
| # echo 1 > /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self => 0x4007e0
| adrp_self() => 0x4007e0
| EQUAL
CVE-2024-50194
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
posix-clock: Fix missing timespec64 check in pc_clock_settime()
As Andrew pointed out, it will make sense that the PTP core
checked timespec64 struct's tv_sec and tv_nsec range before calling
ptp->info->settime64().
As the man manual of clock_settime() said, if tp.tv_sec is negative or
tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
which include dynamic clocks which handles PTP clock, and the condition is
consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
only check the timespec is valid, but not ensure that the time is
in a valid range, so check it ahead using timespec64_valid_strict()
in pc_clock_settime() and return -EINVAL if not valid.
There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
write registers without validity checks and assume that the higher layer
has checked it, which is dangerous and will benefit from this, such as
hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
and some drivers can remove the checks of itself.
CVE-2024-50195
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".
So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.
CVE-2024-50218
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlegacy: Clear stale interrupts before resuming device
iwl4965 fails upon resume from hibernation on my laptop. The reason
seems to be a stale interrupt which isn't being cleared out before
interrupts are enabled. We end up with a race beween the resume
trying to bring things back up, and the restart work (queued form
the interrupt handler) trying to bring things down. Eventually
the whole thing blows up.
Fix the problem by clearing out any stale interrupts before
interrupts get enabled during resume.
Here's a debug log of the indicent:
[ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000
[ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000
[ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.
[ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload
[ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282
[ 12.052207] ieee80211 phy0: il4965_mac_start enter
[ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff
[ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready
[ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions
[ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S
[ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm
[ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm
[ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK
[ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations
[ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up
[ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.
[ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down
[ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout
[ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort
[ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver
[ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared
[ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state
[ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master
[ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.
[ 12.058869] ieee80211 phy0: Hardware restart was requested
[ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.
[ 16.132303] ------------[ cut here ]------------
[ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
[ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev
[ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143
[ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010
[ 16.132463] Workqueue: async async_run_entry_fn
[ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[ 16.132501] Code: da 02 00 0
---truncated---
CVE-2024-50234
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: Fix memory leak in management tx
In the current logic, memory is allocated for storing the MSDU context
during management packet TX but this memory is not being freed during
management TX completion. Similar leaks are seen in the management TX
cleanup logic.
Kmemleak reports this problem as below,
unreferenced object 0xffffff80b64ed250 (size 16):
comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)
hex dump (first 16 bytes):
00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t......
backtrace:
[<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8
[<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110
[<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
[<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
[<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400
[<ffffffe6e78d60b8>] worker_thread+0x208/0x328
[<ffffffe6e78dc890>] kthread+0x100/0x1c0
[<ffffffe6e78166c0>] ret_from_fork+0x10/0x20
Free the memory during completion and cleanup to fix the leak.
Protect the mgmt_pending_tx idr_remove() operation in
ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to
other instances.
Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
CVE-2024-50236
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
Avoid potentially crashing in the driver because of uninitialized private data
CVE-2024-50237
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans
During loopback communication, a dangling pointer can be created in
vsk->trans, potentially leading to a Use-After-Free condition. This
issue is resolved by initializing vsk->trans to NULL.
CVE-2024-50264
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()
Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():
[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry
[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004
[...]
[ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[...]
[ 57.331328] Call Trace:
[ 57.331477] <TASK>
[...]
[ 57.333511] ? do_user_addr_fault+0x3e5/0x740
[ 57.333778] ? exc_page_fault+0x70/0x170
[ 57.334016] ? asm_exc_page_fault+0x2b/0x30
[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0
[ 57.335164] ocfs2_xa_set+0x704/0xcf0
[ 57.335381] ? _raw_spin_unlock+0x1a/0x40
[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20
[ 57.335915] ? trace_preempt_on+0x1e/0x70
[ 57.336153] ? start_this_handle+0x16c/0x500
[ 57.336410] ? preempt_count_sub+0x50/0x80
[ 57.336656] ? _raw_read_unlock+0x20/0x40
[ 57.336906] ? start_this_handle+0x16c/0x500
[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0
[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0
[ 57.337706] ? ocfs2_start_trans+0x13d/0x290
[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0
[ 57.338207] ? dput+0x46/0x1c0
[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30
[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30
[ 57.338948] __vfs_removexattr+0x92/0xc0
[ 57.339182] __vfs_removexattr_locked+0xd5/0x190
[ 57.339456] ? preempt_count_sub+0x50/0x80
[ 57.339705] vfs_removexattr+0x5f/0x100
[...]
Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->
ocfs2_xa_value_truncate() with -ENOMEM.
In this case the comment mentions that we can return 0 if
ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
anyway. But the following 'rc' check is wrong and execution flow do
'ocfs2_xa_remove_entry(loc);' twice:
* 1st: in ocfs2_xa_cleanup_value_truncate();
* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.
Fix this by skipping the 2nd removal of the same entry and making
syzkaller repro happy.
CVE-2024-50265
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: io_edgeport: fix use after free in debug printk
The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb)
is a use after free of the "urb" pointer. Store the "dev" pointer at the
start of the function to avoid this issue.
CVE-2024-50267
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
usb: musb: sunxi: Fix accessing an released usb phy
Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on
exit") will cause that usb phy @glue->xceiv is accessed after released.
1) register platform driver @sunxi_musb_driver
// get the usb phy @glue->xceiv
sunxi_musb_probe() -> devm_usb_get_phy().
2) register and unregister platform driver @musb_driver
musb_probe() -> sunxi_musb_init()
use the phy here
//the phy is released here
musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()
3) register @musb_driver again
musb_probe() -> sunxi_musb_init()
use the phy here but the phy has been released at 2).
...
Fixed by reverting the commit, namely, removing devm_usb_put_phy()
from sunxi_musb_exit().
CVE-2024-50269
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
filemap: Fix bounds checking in filemap_read()
If the caller supplies an iocb->ki_pos value that is close to the
filesystem upper limit, and an iterator with a count that causes us to
overflow that limit, then filemap_read() enters an infinite loop.
This behaviour was discovered when testing xfstests generic/525 with the
"localio" optimisation for loopback NFS mounts.
CVE-2024-50272
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: reinitialize delayed ref list after deleting it from the list
At insert_delayed_ref() if we need to update the action of an existing
ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's
ref_add_list using list_del(), which leaves the ref's add_list member
not reinitialized, as list_del() sets the next and prev members of the
list to LIST_POISON1 and LIST_POISON2, respectively.
If later we end up calling drop_delayed_ref() against the ref, which can
happen during merging or when destroying delayed refs due to a transaction
abort, we can trigger a crash since at drop_delayed_ref() we call
list_empty() against the ref's add_list, which returns false since
the list was not reinitialized after the list_del() and as a consequence
we call list_del() again at drop_delayed_ref(). This results in an
invalid list access since the next and prev members are set to poison
pointers, resulting in a splat if CONFIG_LIST_HARDENED and
CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences
otherwise.
So fix this by deleting from the list with list_del_init() instead.
CVE-2024-50273
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix out-of-bounds access to the dirty bitset when resizing
dm-cache checks the dirty bits of the cache blocks to be dropped when
shrinking the fast device, but an index bug in bitset iteration causes
out-of-bounds access.
Reproduce steps:
1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
2. shrink the fast device to 512 cache blocks, triggering out-of-bounds
access to the dirty bitset (offset 0x80)
dmsetup suspend cache
dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0
Read of size 8 at addr ffffc900000f3080 by task dmsetup/131
(...snip...)
The buggy address belongs to the virtual mapping at
[ffffc900000f3000, ffffc900000f5000) created by:
cache_ctr+0x176a/0x35f0
(...snip...)
Memory state around the buggy address:
ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by making the index post-incremented.
CVE-2024-50279
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: av7110: fix a spectre vulnerability
As warned by smatch:
drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)
There is a spectre-related vulnerability at the code. Fix it.
CVE-2024-50289
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: cx24116: prevent overflows on SNR calculus
as reported by Coverity, if reading SNR registers fail, a negative
number will be returned, causing an underflow when reading SNR
registers.
Prevent that.
CVE-2024-50290
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when uninstalling driver
When the driver is uninstalled and the VF is disabled concurrently, a
kernel crash occurs. The reason is that the two actions call function
pci_disable_sriov(). The num_VFs is checked to determine whether to
release the corresponding resources. During the second calling, num_VFs
is not 0 and the resource release function is called. However, the
corresponding resource has been released during the first invoking.
Therefore, the problem occurs:
[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
...
[15278.131557][T50670] Call trace:
[15278.134686][T50670] klist_put+0x28/0x12c
[15278.138682][T50670] klist_del+0x14/0x20
[15278.142592][T50670] device_del+0xbc/0x3c0
[15278.146676][T50670] pci_remove_bus_device+0x84/0x120
[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80
[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c
[15278.162485][T50670] sriov_disable+0x50/0x11c
[15278.166829][T50670] pci_disable_sriov+0x24/0x30
[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]
[15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge]
[15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230
[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30
[15278.193848][T50670] invoke_syscall+0x50/0x11c
[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164
[15278.203837][T50670] do_el0_svc+0x34/0xcc
[15278.207834][T50670] el0_svc+0x20/0x30
For details, see the following figure.
rmmod hclge disable VFs
----------------------------------------------------
hclge_exit() sriov_numvfs_store()
... device_lock()
pci_disable_sriov() hns3_pci_sriov_configure()
pci_disable_sriov()
sriov_disable()
sriov_disable() if !num_VFs :
if !num_VFs : return;
return; sriov_del_vfs()
sriov_del_vfs() ...
... klist_put()
klist_put() ...
... num_VFs = 0;
num_VFs = 0; device_unlock();
In this patch, when driver is removing, we get the device_lock()
to protect num_VFs, just like sriov_numvfs_store().
CVE-2024-50296
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
security/keys: fix slab-out-of-bounds in key_task_permission
KASAN reports an out of bounds read:
BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36
BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]
BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410
security/keys/permission.c:54
Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362
CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15
Call Trace:
__dump_stack lib/dump_stack.c:82 [inline]
dump_stack+0x107/0x167 lib/dump_stack.c:123
print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400
__kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
kasan_report+0x3a/0x50 mm/kasan/report.c:585
__kuid_val include/linux/uidgid.h:36 [inline]
uid_eq include/linux/uidgid.h:63 [inline]
key_task_permission+0x394/0x410 security/keys/permission.c:54
search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793
This issue was also reported by syzbot.
It can be reproduced by following these steps(more details [1]):
1. Obtain more than 32 inputs that have similar hashes, which ends with the
pattern '0xxxxxxxe6'.
2. Reboot and add the keys obtained in step 1.
The reproducer demonstrates how this issue happened:
1. In the search_nested_keyrings function, when it iterates through the
slots in a node(below tag ascend_to_node), if the slot pointer is meta
and node->back_pointer != NULL(it means a root), it will proceed to
descend_to_node. However, there is an exception. If node is the root,
and one of the slots points to a shortcut, it will be treated as a
keyring.
2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as
ASSOC_ARRAY_PTR_SUBTYPE_MASK.
3. When 32 keys with the similar hashes are added to the tree, the ROOT
has keys with hashes that are not similar (e.g. slot 0) and it splits
NODE A without using a shortcut. When NODE A is filled with keys that
all hashes are xxe6, the keys are similar, NODE A will split with a
shortcut. Finally, it forms the tree as shown below, where slot 6 points
to a shortcut.
NODE A
+------>+---+
ROOT | | 0 | xxe6
+---+ | +---+
xxxx | 0 | shortcut : : xxe6
+---+ | +---+
xxe6 : : | | | xxe6
+---+ | +---+
| 6 |---+ : : xxe6
+---+ +---+
xxe6 : : | f | xxe6
+---+ +---+
xxe6 | f |
+---+
4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,
it may be mistakenly transferred to a key*, leading to a read
out-of-bounds read.
To fix this issue, one should jump to descend_to_node if the ptr is a
shortcut, regardless of whether the node is root or not.
[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/
[jarkko: tweaked the commit message a bit to have an appropriate closes
tag.]
CVE-2024-50301
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
HID: core: zero-initialize the report buffer
Since the report buffer is used by all kinds of drivers in various ways, let's
zero-initialize it during allocation to make sure that it can't be ever used
to leak kernel memory via specially-crafted report.
CVE-2024-50302
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.
CVE-2024-50602
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing '\0' character.
CVE-2024-52533
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
important
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()
The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32
values that come from the user via the submit_lookup_cmds() function.
This addition could lead to an integer wrapping bug so use size_add()
to prevent that.
Patchwork: https://patchwork.freedesktop.org/patch/624696/
CVE-2024-52559
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.
CVE-2024-52615
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-client3-0.6.32-32.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-common3-0.6.32-32.33.1
moderate
A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.
CVE-2024-52616
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-client3-0.6.32-32.33.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libavahi-common3-0.6.32-32.33.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
In case the non-paged data of a SKB carries protocol header and protocol
payload to be transmitted on a certain platform that the DMA AXI address
width is configured to 40-bit/48-bit, or the size of the non-paged data
is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI
address width is configured to 32-bit, then this SKB requires at least
two DMA transmit descriptors to serve it.
For example, three descriptors are allocated to split one DMA buffer
mapped from one piece of non-paged data:
dma_desc[N + 0],
dma_desc[N + 1],
dma_desc[N + 2].
Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold
extra information to be reused in stmmac_tx_clean():
tx_q->tx_skbuff_dma[N + 0],
tx_q->tx_skbuff_dma[N + 1],
tx_q->tx_skbuff_dma[N + 2].
Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer
address returned by DMA mapping call. stmmac_tx_clean() will try to
unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf
is a valid buffer address.
The expected behavior that saves DMA buffer address of this non-paged
data to tx_q->tx_skbuff_dma[entry].buf is:
tx_q->tx_skbuff_dma[N + 0].buf = NULL;
tx_q->tx_skbuff_dma[N + 1].buf = NULL;
tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();
Unfortunately, the current code misbehaves like this:
tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single();
tx_q->tx_skbuff_dma[N + 1].buf = NULL;
tx_q->tx_skbuff_dma[N + 2].buf = NULL;
On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the
DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address
obviously, then the DMA buffer will be unmapped immediately.
There may be a rare case that the DMA engine does not finish the
pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go
horribly wrong, DMA is going to access a unmapped/unreferenced memory
region, corrupted data will be transmited or iommu fault will be
triggered :(
In contrast, the for-loop that maps SKB fragments behaves perfectly
as expected, and that is how the driver should do for both non-paged
data and paged frags actually.
This patch corrects DMA map/unmap sequences by fixing the array index
for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.
Tested and verified on DWXGMAC CORE 3.20a
CVE-2024-53058
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: s5p-jpeg: prevent buffer overflows
The current logic allows word to be less than 2. If this happens,
there will be buffer overflows, as reported by smatch. Add extra
checks to prevent it.
While here, remove an unused word = 0 assignment.
CVE-2024-53061
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
media: dvbdev: prevent the risk of out of memory access
The dvbdev contains a static variable used to store dvb minors.
The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set
or not. When not set, dvb_register_device() won't check for
boundaries, as it will rely that a previous call to
dvb_register_adapter() would already be enforcing it.
On a similar way, dvb_device_open() uses the assumption
that the register functions already did the needed checks.
This can be fragile if some device ends using different
calls. This also generate warnings on static check analysers
like Coverity.
So, add explicit guards to prevent potential risk of OOM issues.
CVE-2024-53063
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nfs: Fix KMSAN warning in decode_getfattr_attrs()
Fix the following KMSAN warning:
CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B
Tainted: [B]=BAD_PAGE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
=====================================================
=====================================================
BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90
decode_getfattr_attrs+0x2d6d/0x2f90
decode_getfattr_generic+0x806/0xb00
nfs4_xdr_dec_getattr+0x1de/0x240
rpcauth_unwrap_resp_decode+0xab/0x100
rpcauth_unwrap_resp+0x95/0xc0
call_decode+0x4ff/0xb50
__rpc_execute+0x57b/0x19d0
rpc_execute+0x368/0x5e0
rpc_run_task+0xcfe/0xee0
nfs4_proc_getattr+0x5b5/0x990
__nfs_revalidate_inode+0x477/0xd00
nfs_access_get_cached+0x1021/0x1cc0
nfs_do_access+0x9f/0xae0
nfs_permission+0x1e4/0x8c0
inode_permission+0x356/0x6c0
link_path_walk+0x958/0x1330
path_lookupat+0xce/0x6b0
filename_lookup+0x23e/0x770
vfs_statx+0xe7/0x970
vfs_fstatat+0x1f2/0x2c0
__se_sys_newfstatat+0x67/0x880
__x64_sys_newfstatat+0xbd/0x120
x64_sys_call+0x1826/0x3cf0
do_syscall_64+0xd0/0x1b0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The KMSAN warning is triggered in decode_getfattr_attrs(), when calling
decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not
initialized.
Fix the issue by initializing fattr->mdsthreshold to NULL in
nfs_fattr_init().
CVE-2024-53066
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tpm: Lock TPM chip in tpm_pm_suspend() first
Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy
according, as this leaves window for tpm_hwrng_read() to be called while
the operation is in progress. The recent bug report gives also evidence of
this behaviour.
Aadress this by locking the TPM chip before checking any chip->flags both
in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED
check inside tpm_get_random() so that it will be always checked only when
the lock is reserved.
CVE-2024-53085
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix race condition by adding filter's intermediate sync state
Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.
1. Thread T0 allocates a filter in i40e_add_filter() within
i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
refers to the already freed filter memory, causing corruption.
Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
please set promiscuous on manually for VF XX".
Exact code for stable reproduction Intel can't open-source now.
The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process.
CVE-2024-53088
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format
This can lead to out of bounds writes since frames of this type were not
taken into account when calculating the size of the frames buffer in
uvc_parse_streaming.
CVE-2024-53104
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client
A number of Zen4 client SoCs advertise the ability to use virtualized
VMLOAD/VMSAVE, but using these instructions is reported to be a cause
of a random host reboot.
These instructions aren't intended to be advertised on Zen4 client
so clear the capability.
CVE-2024-53114
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fix data-races around sk->sk_forward_alloc
Syzkaller reported this warning:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0
Modules linked in:
CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:inet_sock_destruct+0x1c5/0x1e0
Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00
RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206
RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007
RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00
RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007
R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00
R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78
FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? __warn+0x88/0x130
? inet_sock_destruct+0x1c5/0x1e0
? report_bug+0x18e/0x1a0
? handle_bug+0x53/0x90
? exc_invalid_op+0x18/0x70
? asm_exc_invalid_op+0x1a/0x20
? inet_sock_destruct+0x1c5/0x1e0
__sk_destruct+0x2a/0x200
rcu_do_batch+0x1aa/0x530
? rcu_do_batch+0x13b/0x530
rcu_core+0x159/0x2f0
handle_softirqs+0xd3/0x2b0
? __pfx_smpboot_thread_fn+0x10/0x10
run_ksoftirqd+0x25/0x30
smpboot_thread_fn+0xdd/0x1d0
kthread+0xd3/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---
Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()
concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,
which triggers a data-race around sk->sk_forward_alloc:
tcp_v6_rcv
tcp_v6_do_rcv
skb_clone_and_charge_r
sk_rmem_schedule
__sk_mem_schedule
sk_forward_alloc_add()
skb_set_owner_r
sk_mem_charge
sk_forward_alloc_add()
__kfree_skb
skb_release_all
skb_release_head_state
sock_rfree
sk_mem_uncharge
sk_forward_alloc_add()
sk_mem_reclaim
// set local var reclaimable
__sk_mem_reclaim
sk_forward_alloc_add()
In this syzkaller testcase, two threads call
tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like
this:
(cpu 1) | (cpu 2) | sk_forward_alloc
... | ... | 0
__sk_mem_schedule() | | +4096 = 4096
| __sk_mem_schedule() | +4096 = 8192
sk_mem_charge() | | -768 = 7424
| sk_mem_charge() | -768 = 6656
... | ... |
sk_mem_uncharge() | | +768 = 7424
reclaimable=7424 | |
| sk_mem_uncharge() | +768 = 8192
| reclaimable=8192 |
__sk_mem_reclaim() | | -4096 = 4096
| __sk_mem_reclaim() | -8192 = -4096 != 0
The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when
sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().
Fix the same issue in dccp_v6_do_rcv().
CVE-2024-53124
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netlink: terminate outstanding dump on socket close
Netlink supports iterative dumping of data. It provides the families
the following ops:
- start - (optional) kicks off the dumping process
- dump - actual dump helper, keeps getting called until it returns 0
- done - (optional) pairs with .start, can be used for cleanup
The whole process is asynchronous and the repeated calls to .dump
don't actually happen in a tight loop, but rather are triggered
in response to recvmsg() on the socket.
This gives the user full control over the dump, but also means that
the user can close the socket without getting to the end of the dump.
To make sure .start is always paired with .done we check if there
is an ongoing dump before freeing the socket, and if so call .done.
The complication is that sockets can get freed from BH and .done
is allowed to sleep. So we use a workqueue to defer the call, when
needed.
Unfortunately this does not work correctly. What we defer is not
the cleanup but rather releasing a reference on the socket.
We have no guarantee that we own the last reference, if someone
else holds the socket they may release it in BH and we're back
to square one.
The whole dance, however, appears to be unnecessary. Only the user
can interact with dumps, so we can clean up when socket is closed.
And close always happens in process context. Some async code may
still access the socket after close, queue notification skbs to it etc.
but no dumps can start, end or otherwise make progress.
Delete the workqueue and flush the dump state directly from the release
handler. Note that further cleanup is possible in -next, for instance
we now always call .done before releasing the main module reference,
so dump doesn't have to take a reference of its own.
CVE-2024-53140
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
initramfs: avoid filename buffer overrun
The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:
37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
...
55 ============= ================== =========================
56 Field name Field size Meaning
57 ============= ================== =========================
...
70 c_namesize 8 bytes Length of filename, including final \0
When extracting an initramfs cpio archive, the kernel's do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().
If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn't be considered a security
vulnerability.
Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
./reproducer.sh | gzip >> /myinitramfs
It's easiest to observe non-zero uninitialized memory when the output is
gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.
---- reproducer.sh ----
nilchar="A" # change to "\0" to properly zero terminate / pad
magic="070701"
ino=1
mode=$(( 0100777 ))
uid=0
gid=0
nlink=1
mtime=1
filesize=0
devmajor=0
devminor=1
rdevmajor=0
rdevminor=0
csum=0
fname="initramfs_test_fname_overrun"
namelen=$(( ${#fname} + 1 )) # plus one to account for terminator
printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \
$magic $ino $mode $uid $gid $nlink $mtime $filesize \
$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname
termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) ))
printf "%.s${nilchar}" $(seq 1 $termpadlen)
---- reproducer.sh ----
Symlink filename fields handled in do_symlink() won't overrun past the
data segment, due to the explicit zero-termination of the symlink
target.
Fix filename buffer overrun by aborting the initramfs FSM if any cpio
entry doesn't carry a zero-terminator at the expected (name_len - 1)
offset.
CVE-2024-53142
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket
BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0
Read of size 1 at addr ffff888111f322cd by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
Call Trace:
<IRQ>
dump_stack_lvl+0x68/0xa0
print_address_description.constprop.0+0x2c/0x3d0
print_report+0xb4/0x270
kasan_report+0xbd/0xf0
tcp_write_timer_handler+0x156/0x3e0
tcp_write_timer+0x66/0x170
call_timer_fn+0xfb/0x1d0
__run_timers+0x3f8/0x480
run_timer_softirq+0x9b/0x100
handle_softirqs+0x153/0x390
__irq_exit_rcu+0x103/0x120
irq_exit_rcu+0xe/0x20
sysvec_apic_timer_interrupt+0x76/0x90
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:default_idle+0xf/0x20
Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc
cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242
RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d
R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0
default_idle_call+0x6b/0xa0
cpuidle_idle_call+0x1af/0x1f0
do_idle+0xbc/0x130
cpu_startup_entry+0x33/0x40
rest_init+0x11f/0x210
start_kernel+0x39a/0x420
x86_64_start_reservations+0x18/0x30
x86_64_start_kernel+0x97/0xa0
common_startup_64+0x13e/0x141
</TASK>
Allocated by task 595:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
__kasan_slab_alloc+0x87/0x90
kmem_cache_alloc_noprof+0x12b/0x3f0
copy_net_ns+0x94/0x380
create_new_namespaces+0x24c/0x500
unshare_nsproxy_namespaces+0x75/0xf0
ksys_unshare+0x24e/0x4f0
__x64_sys_unshare+0x1f/0x30
do_syscall_64+0x70/0x180
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 100:
kasan_save_stack+0x24/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x54/0x70
kmem_cache_free+0x156/0x5d0
cleanup_net+0x5d3/0x670
process_one_work+0x776/0xa90
worker_thread+0x2e2/0x560
kthread+0x1a8/0x1f0
ret_from_fork+0x34/0x60
ret_from_fork_asm+0x1a/0x30
Reproduction script:
mkdir -p /mnt/nfsshare
mkdir -p /mnt/nfs/netns_1
mkfs.ext4 /dev/sdb
mount /dev/sdb /mnt/nfsshare
systemctl restart nfs-server
chmod 777 /mnt/nfsshare
exportfs -i -o rw,no_root_squash *:/mnt/nfsshare
ip netns add netns_1
ip link add name veth_1_peer type veth peer veth_1
ifconfig veth_1_peer 11.11.0.254 up
ip link set veth_1 netns netns_1
ip netns exec netns_1 ifconfig veth_1 11.11.0.1
ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \
--tcp-flags FIN FIN -j DROP
(note: In my environment, a DESTROY_CLIENTID operation is always sent
immediately, breaking the nfs tcp connection.)
ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \
11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1
ip netns del netns_1
The reason here is that the tcp socket in netns_1 (nfs side) has been
shutdown and closed (done in xs_destroy), but the FIN message (with ack)
is discarded, and the nfsd side keeps sending retransmission messages.
As a result, when the tcp sock in netns_1 processes the received message,
it sends the message (FIN message) in the sending queue, and the tcp timer
is re-established. When the network namespace is deleted, the net structure
accessed by tcp's timer handler function causes problems.
To fix this problem, let's hold netns refcnt for the tcp kernel socket as
done in other modules. This is an ugly hack which can easily be backported
to earlier kernels. A proper fix which cleans up the interfaces will
follow, but may not be so easy to backport.
CVE-2024-53168
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix use-after-free of slot->bus on hot remove
Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.
Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and
commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot
firmware"), USB4 v2 and v1 Host Routers are reset on probe of the
thunderbolt driver.
The reset clears the Presence Detect State and Data Link Layer Link Active
bits at the USB4 Host Router's Root Port and thus causes hot removal of the
dock.
The crash occurs when pciehp is unbound from one of the dock's Downstream
Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The
pci_slot contains a pointer to the pci_bus below the Downstream Port, but
a reference on that pci_bus is never acquired. The pci_bus is destroyed
before the pci_slot, so a use-after-free ensues when pci_slot_release()
accesses slot->bus.
In principle this should not happen because pci_stop_bus_device() unbinds
pciehp (and therefore destroys the pci_slot) before the pci_bus is
destroyed by pci_remove_bus_device().
However the stacktrace provided by Dennis shows that pciehp is unbound from
pci_remove_bus_device() instead of pci_stop_bus_device(). To understand
the significance of this, one needs to know that the PCI core uses a two
step process to remove a portion of the hierarchy: It first unbinds all
drivers in the sub-hierarchy in pci_stop_bus_device() and then actually
removes the devices in pci_remove_bus_device(). There is no precaution to
prevent driver binding in-between pci_stop_bus_device() and
pci_remove_bus_device().
In Dennis' case, it seems removal of the hierarchy by pciehp races with
driver binding by pci_bus_add_devices(). pciehp is bound to the
Downstream Port after pci_stop_bus_device() has run, so it is unbound by
pci_remove_bus_device() instead of pci_stop_bus_device(). Because the
pci_bus has already been destroyed at that point, accesses to it result in
a use-after-free.
One might conclude that driver binding needs to be prevented after
pci_stop_bus_device() has run. However it seems risky that pci_slot points
to pci_bus without holding a reference. Solely relying on correct ordering
of driver unbind versus pci_bus destruction is certainly not defensive
programming.
If pci_slot has a need to access data in pci_bus, it ought to acquire a
reference. Amend pci_create_slot() accordingly. Dennis reports that the
crash is not reproducible with this change.
Abridged stacktrace:
pcieport 0000:00:07.0: PME: Signaling with IRQ 156
pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
pci_bus 0000:20: dev 00, created physical slot 12
pcieport 0000:00:07.0: pciehp: Slot(12): Card not present
...
pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0
Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1
RIP: 0010:dev_driver_string+0x12/0x40
pci_destroy_slot
pciehp_remove
pcie_port_remove_service
device_release_driver_internal
bus_remove_device
device_del
device_unregister
remove_iter
device_for_each_child
pcie_portdrv_remove
pci_device_remove
device_release_driver_internal
bus_remove_device
device_del
pci_remove_bus_device (recursive invocation)
pci_remove_bus_device
pciehp_unconfigure_device
pciehp_disable_slot
pciehp_handle_presence_or_link_change
pciehp_ist
CVE-2024-53194
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()
Under certain kernel configurations when building with Clang/LLVM, the
compiler does not generate a return or jump as the terminator
instruction for ip_vs_protocol_init(), triggering the following objtool
warning during build time:
vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()
At runtime, this either causes an oops when trying to load the ipvs
module or a boot-time panic if ipvs is built-in. This same issue has
been reported by the Intel kernel test robot previously.
Digging deeper into both LLVM and the kernel code reveals this to be a
undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer
of 64 chars to store the registered protocol names and leaves it
uninitialized after definition. The function calls strnlen() when
concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE
strnlen() performs an extra step to check whether the last byte of the
input char buffer is a null character (commit 3009f891bb9f ("fortify:
Allow strlen() and strnlen() to pass compile-time known lengths")).
This, together with possibly other configurations, cause the following
IR to be generated:
define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 {
%1 = alloca [64 x i8], align 16
...
14: ; preds = %11
%15 = getelementptr inbounds i8, ptr %1, i64 63
%16 = load i8, ptr %15, align 1
%17 = tail call i1 @llvm.is.constant.i8(i8 %16)
%18 = icmp eq i8 %16, 0
%19 = select i1 %17, i1 %18, i1 false
br i1 %19, label %20, label %23
20: ; preds = %14
%21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23
...
23: ; preds = %14, %11, %20
%24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24
...
}
The above code calculates the address of the last char in the buffer
(value %15) and then loads from it (value %16). Because the buffer is
never initialized, the LLVM GVN pass marks value %16 as undefined:
%13 = getelementptr inbounds i8, ptr %1, i64 63
br i1 undef, label %14, label %17
This gives later passes (SCCP, in particular) more DCE opportunities by
propagating the undef value further, and eventually removes everything
after the load on the uninitialized stack location:
define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 {
%1 = alloca [64 x i8], align 16
...
12: ; preds = %11
%13 = getelementptr inbounds i8, ptr %1, i64 63
unreachable
}
In this way, the generated native code will just fall through to the
next function, as LLVM does not generate any code for the unreachable IR
instruction and leaves the function without a terminator.
Zero the on-stack buffer to avoid this possible UB.
CVE-2024-53680
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: IDLETIMER: Fix for possible ABBA deadlock
Deletion of the last rule referencing a given idletimer may happen at
the same time as a read of its file in sysfs:
| ======================================================
| WARNING: possible circular locking dependency detected
| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted
| ------------------------------------------------------
| iptables/3303 is trying to acquire lock:
| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20
|
| but task is already holding lock:
| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]
|
| which lock already depends on the new lock.
A simple reproducer is:
| #!/bin/bash
|
| while true; do
| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
| done &
| while true; do
| cat /sys/class/xt_idletimer/timers/testme >/dev/null
| done
Avoid this by freeing list_mutex right after deleting the element from
the list, then continuing with the teardown.
CVE-2024-54683
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an
empty supported client protocols buffer may cause a crash or memory contents to
be sent to the peer.
Impact summary: A buffer overread can have a range of potential consequences
such as unexpected application beahviour or a crash. In particular this issue
could result in up to 255 bytes of arbitrary private data from memory being sent
to the peer leading to a loss of confidentiality. However, only applications
that directly call the SSL_select_next_proto function with a 0 length list of
supported client protocols are affected by this issue. This would normally never
be a valid scenario and is typically not under attacker control but may occur by
accident in the case of a configuration or programming error in the calling
application.
The OpenSSL API function SSL_select_next_proto is typically used by TLS
applications that support ALPN (Application Layer Protocol Negotiation) or NPN
(Next Protocol Negotiation). NPN is older, was never standardised and
is deprecated in favour of ALPN. We believe that ALPN is significantly more
widely deployed than NPN. The SSL_select_next_proto function accepts a list of
protocols from the server and a list of protocols from the client and returns
the first protocol that appears in the server list that also appears in the
client list. In the case of no overlap between the two lists it returns the
first item in the client list. In either case it will signal whether an overlap
between the two lists was found. In the case where SSL_select_next_proto is
called with a zero length client list it fails to notice this condition and
returns the memory immediately following the client list pointer (and reports
that there was no overlap in the lists).
This function is typically called from a server side application callback for
ALPN or a client side application callback for NPN. In the case of ALPN the list
of protocols supplied by the client is guaranteed by libssl to never be zero in
length. The list of server protocols comes from the application and should never
normally be expected to be of zero length. In this case if the
SSL_select_next_proto function has been called as expected (with the list
supplied by the client passed in the client/client_len parameters), then the
application will not be vulnerable to this issue. If the application has
accidentally been configured with a zero length server list, and has
accidentally passed that zero length server list in the client/client_len
parameters, and has additionally failed to correctly handle a "no overlap"
response (which would normally result in a handshake failure in ALPN) then it
will be vulnerable to this problem.
In the case of NPN, the protocol permits the client to opportunistically select
a protocol when there is no overlap. OpenSSL returns the first client protocol
in the no overlap case in support of this. The list of client protocols comes
from the application and should never normally be expected to be of zero length.
However if the SSL_select_next_proto function is accidentally called with a
client_len of 0 then an invalid memory pointer will be returned instead. If the
application uses this output as the opportunistic protocol then the loss of
confidentiality will occur.
This issue has been assessed as Low severity because applications are most
likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not
widely used. It also requires an application configuration or programming error.
Finally, this issue would not typically be under attacker control making active
exploitation unlikely.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available.
CVE-2024-5535
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_0_0-1.0.2p-3.98.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:openssl-1_0_0-1.0.2p-3.98.1
moderate
xsltGetInheritedNsList in libxslt before 1.1.43 has a use-after-free issue related to exclusion of result prefixes.
CVE-2024-55549
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxslt1-1.1.28-17.21.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:libxml2-2-2.9.4-46.93.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).
CVE-2024-5642
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet
This fixes not checking if skb really contains an ACL header otherwise
the code may attempt to access some uninitilized/invalid memory past the
valid skb->data.
CVE-2024-56590
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix LGR and link use-after-free issue
We encountered a LGR/link use-after-free issue, which manifested as
the LGR/link refcnt reaching 0 early and entering the clear process,
making resource access unsafe.
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140
Workqueue: events smc_lgr_terminate_work [smc]
Call trace:
refcount_warn_saturate+0x9c/0x140
__smc_lgr_terminate.part.45+0x2a8/0x370 [smc]
smc_lgr_terminate_work+0x28/0x30 [smc]
process_one_work+0x1b8/0x420
worker_thread+0x158/0x510
kthread+0x114/0x118
or
refcount_t: underflow; use-after-free.
WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140
Workqueue: smc_hs_wq smc_listen_work [smc]
Call trace:
refcount_warn_saturate+0xf0/0x140
smcr_link_put+0x1cc/0x1d8 [smc]
smc_conn_free+0x110/0x1b0 [smc]
smc_conn_abort+0x50/0x60 [smc]
smc_listen_find_device+0x75c/0x790 [smc]
smc_listen_work+0x368/0x8a0 [smc]
process_one_work+0x1b8/0x420
worker_thread+0x158/0x510
kthread+0x114/0x118
It is caused by repeated release of LGR/link refcnt. One suspect is that
smc_conn_free() is called repeatedly because some smc_conn_free() from
server listening path are not protected by sock lock.
e.g.
Calls under socklock | smc_listen_work
-------------------------------------------------------
lock_sock(sk) | smc_conn_abort
smc_conn_free | \- smc_conn_free
\- smcr_link_put | \- smcr_link_put (duplicated)
release_sock(sk)
So here add sock lock protection in smc_listen_work() path, making it
exclusive with other connection operations.
CVE-2024-56640
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
important
GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.
CVE-2024-56738
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: netem: account for backlog updates from child qdisc
In general, 'qlen' of any classful qdisc should keep track of the
number of packets that the qdisc itself and all of its children holds.
In case of netem, 'qlen' only accounts for the packets in its internal
tfifo. When netem is used with a child qdisc, the child qdisc can use
'qdisc_tree_reduce_backlog' to inform its parent, netem, about created
or dropped SKBs. This function updates 'qlen' and the backlog statistics
of netem, but netem does not account for changes made by a child qdisc.
'qlen' then indicates the wrong number of packets in the tfifo.
If a child qdisc creates new SKBs during enqueue and informs its parent
about this, netem's 'qlen' value is increased. When netem dequeues the
newly created SKBs from the child, the 'qlen' in netem is not updated.
If 'qlen' reaches the configured sch->limit, the enqueue function stops
working, even though the tfifo is not full.
Reproduce the bug:
Ensure that the sender machine has GSO enabled. Configure netem as root
qdisc and tbf as its child on the outgoing interface of the machine
as follows:
$ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100
$ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms
Send bulk TCP traffic out via this interface, e.g., by running an iPerf3
client on the machine. Check the qdisc statistics:
$ tc -s qdisc show dev <oif>
Statistics after 10s of iPerf3 TCP test before the fix (note that
netem's backlog > limit, netem stopped accepting packets):
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)
backlog 4294528236b 1155p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)
backlog 0b 0p requeues 0
Statistics after the fix:
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)
backlog 0b 0p requeues 0
tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.
The interface fully stops transferring packets and "locks". In this case,
the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at
its limit and no more packets are accepted.
This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is
only decreased when a packet is returned by its dequeue function, and not
during enqueuing into the child qdisc. External updates to 'qlen' are thus
accounted for and only the behavior of the backlog statistics changes. As
in other qdiscs, 'qlen' then keeps track of how many packets are held in
netem and all of its children. As before, sch->limit remains as the
maximum number of packets in the tfifo. The same applies to netem's
backlog statistics.
CVE-2024-56770
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even
umount operation may ultimately fail if some files remain open.
Consequently, if an action attempts to open a file, it can potentially
send two rpc_task to nfs server.
NFS CLIENT
thread1 thread2
open("file")
...
nfs4_do_open
_nfs4_do_open
_nfs4_open_and_get_state
_nfs4_proc_open
nfs4_run_open_task
/* rpc_task1 */
rpc_run_task
rpc_wait_for_completion_task
umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task1 been wakeup
and return -512
_nfs4_do_open // while loop
...
nfs4_run_open_task
/* rpc_task2 */
rpc_run_task
rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or
allocate an nfs4_openowner. If it finds an nfs4_openowner that is not
marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since
two rpc_task can attempt to open the same file simultaneously from the
client to server, and because two instances of nfsd can run
concurrently, this situation can lead to lots of memory leak.
Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be
triggered.
NFS SERVER
nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open
nfsd4_process_open1
find_or_alloc_open_stateowner
// alloc oo1, stateid1
nfsd4_open
nfsd4_process_open1
find_or_alloc_open_stateowner
// find oo1, without NFS4_OO_CONFIRMED
release_openowner
unhash_openowner_locked
list_del_init(&oo->oo_perclient)
// cannot find this oo
// from client, LEAK!!!
alloc_stateowner // alloc oo2
nfsd4_process_open2
init_open_stateid
// associate oo1
// with stateid1, stateid1 LEAK!!!
nfs4_get_vfs_file
// alloc nfsd_file1 and nfsd_file_mark1
// all LEAK!!!
nfsd4_process_open2
...
write_threads
...
nfsd_destroy_serv
nfsd_shutdown_net
nfs4_state_shutdown_net
nfs4_state_destroy_net
destroy_client
__destroy_client
// won't find oo1!!!
nfsd_shutdown_generic
nfsd_file_cache_shutdown
kmem_cache_destroy
for nfsd_file_slab
and nfsd_file_mark_slab
// bark since nfsd_file1
// and nfsd_file_mark1
// still alive
=======================================================================
BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on
__kmem_cache_shutdown()
-----------------------------------------------------------------------
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28
flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)
CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
Call Trace:
<TASK>
dum
---truncated---
CVE-2024-56779
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ila: serialize calls to nf_register_net_hooks()
syzbot found a race in ila_add_mapping() [1]
commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")
attempted to fix a similar issue.
Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.
Add a mutex to make sure at most one thread is calling nf_register_net_hooks().
[1]
BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501
CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xc3/0x620 mm/kasan/report.c:489
kasan_report+0xd9/0x110 mm/kasan/report.c:602
rht_key_hashfn include/linux/rhashtable.h:159 [inline]
__rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
rhashtable_lookup include/linux/rhashtable.h:646 [inline]
rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]
ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]
ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626
nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269
NF_HOOK include/linux/netfilter.h:312 [inline]
ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309
__netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672
__netif_receive_skb+0x1d/0x160 net/core/dev.c:5785
process_backlog+0x443/0x15f0 net/core/dev.c:6117
__napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883
napi_poll net/core/dev.c:6952 [inline]
net_rx_action+0xa94/0x1010 net/core/dev.c:7074
handle_softirqs+0x213/0x8f0 kernel/softirq.c:561
__do_softirq kernel/softirq.c:595 [inline]
invoke_softirq kernel/softirq.c:435 [inline]
__irq_exit_rcu+0x109/0x170 kernel/softirq.c:662
irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049
CVE-2024-57900
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: relax assertions on failure to encode file handles
Encoding file handles is usually performed by a filesystem >encode_fh()
method that may fail for various reasons.
The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.
There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when ->encode_fh() fails.
Relax those assertions because they are wrong.
The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
encoding non-decodable file handles") in v6.6 as the regressing commit,
but this is not accurate.
The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.
Triggering this assertion was always possible with other filesystems and
other reasons of ->encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlayfs that is
mounted with options index=on,nfs_export=on also on kernels < v6.6.
Therefore, I am not listing the aforementioned commit as a Fixes commit.
Backport hint: this patch will have a trivial conflict applying to
v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
CVE-2024-57924
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rdma/cxgb4: Prevent potential integer overflow on 32bit
The "gl->tot_len" variable is controlled by the user. It comes from
process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct
cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an
integer wrapping bug. Use size_add() to prevent this.
CVE-2024-57973
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pps: Fix a use-after-free
On a board running ntpd and gpsd, I'm seeing a consistent use-after-free
in sys_exit() from gpsd when rebooting:
pps pps1: removed
------------[ cut here ]------------
kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.
WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150
CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1
Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kobject_put+0x120/0x150
lr : kobject_put+0x120/0x150
sp : ffffffc0803d3ae0
x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001
x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440
x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600
x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20
x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
kobject_put+0x120/0x150
cdev_put+0x20/0x3c
__fput+0x2c4/0x2d8
____fput+0x1c/0x38
task_work_run+0x70/0xfc
do_exit+0x2a0/0x924
do_group_exit+0x34/0x90
get_signal+0x7fc/0x8c0
do_signal+0x128/0x13b4
do_notify_resume+0xdc/0x160
el0_svc+0xd4/0xf8
el0t_64_sync_handler+0x140/0x14c
el0t_64_sync+0x190/0x194
---[ end trace 0000000000000000 ]---
...followed by more symptoms of corruption, with similar stacks:
refcount_t: underflow; use-after-free.
kernel BUG at lib/list_debug.c:62!
Kernel panic - not syncing: Oops - BUG: Fatal exception
This happens because pps_device_destruct() frees the pps_device with the
embedded cdev immediately after calling cdev_del(), but, as the comment
above cdev_del() notes, fops for previously opened cdevs are still
callable even after cdev_del() returns. I think this bug has always
been there: I can't explain why it suddenly started happening every time
I reboot this particular board.
In commit d953e0e837e6 ("pps: Fix a use-after free bug when
unregistering a source."), George Spelvin suggested removing the
embedded cdev. That seems like the simplest way to fix this, so I've
implemented his suggestion, using __register_chrdev() with pps_idr
becoming the source of truth for which minor corresponds to which
device.
But now that pps_idr defines userspace visibility instead of cdev_add(),
we need to be sure the pps->dev refcount can't reach zero while
userspace can still find it again. So, the idr_remove() call moves to
pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev.
pps_core: source serial1 got cdev (251:1)
<...>
pps pps1: removed
pps_core: unregistering pps1
pps_core: deallocating pps1
CVE-2024-57979
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix double free in error path
If the uvc_status_init() function fails to allocate the int_urb, it will
free the dev->status pointer but doesn't reset the pointer to NULL. This
results in the kfree() call in uvc_status_cleanup() trying to
double-free the memory. Fix it by resetting the dev->status pointer to
NULL after freeing it.
Reviewed by: Ricardo Ribalda <ribalda@chromium.org>
CVE-2024-57980
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Fix NULL pointer dereference on certain command aborts
If a command is queued to the final usable TRB of a ring segment, the
enqueue pointer is advanced to the subsequent link TRB and no further.
If the command is later aborted, when the abort completion is handled
the dequeue pointer is advanced to the first TRB of the next segment.
If no further commands are queued, xhci_handle_stopped_cmd_ring() sees
the ring pointers unequal and assumes that there is a pending command,
so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.
Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell
ring likely is unnecessary too, but it's harmless. Leave it alone.
This is probably Bug 219532, but no confirmation has been received.
The issue has been independently reproduced and confirmed fixed using
a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.
Everything continued working normally after several prevented crashes.
CVE-2024-57981
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: fix out-of-bounds read during lookup
lookup and resize can run in parallel.
The xfrm_state_hash_generation seqlock ensures a retry, but the hash
functions can observe a hmask value that is too large for the new hlist
array.
rehash does:
rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..]
net->xfrm.state_hmask = nhashmask;
While state lookup does:
h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);
hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {
This is only safe in case the update to state_bydst is larger than
net->xfrm.xfrm_state_hmask (or if the lookup function gets
serialized via state spinlock again).
Fix this by prefetching state_hmask and the associated pointers.
The xfrm_state_hash_generation seqlock retry will ensure that the pointer
and the hmask will be consistent.
The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,
add lockdep assertions to document that they are only safe for insert
side.
xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.
AFAICS this is an oversight from back when state lookup was converted to
RCU, this lock should be replaced with RCU in a future patch.
CVE-2024-57982
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: don't allow 1 packet limit
The current implementation does not work correctly with a limit of
1. iproute2 actually checks for this and this patch adds the check in
kernel as well.
This fixes the following syzkaller reported crash:
UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6
index 65535 is out of range for type 'struct sfq_head[128]'
CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x125/0x19f lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:148 [inline]
__ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347
sfq_link net/sched/sch_sfq.c:210 [inline]
sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238
sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500
sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525
qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319
qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296
netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]
dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362
__dev_close_many+0x214/0x350 net/core/dev.c:1468
dev_close_many+0x207/0x510 net/core/dev.c:1506
unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738
unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695
unregister_netdevice include/linux/netdevice.h:2893 [inline]
__tun_detach+0x6b6/0x1600 drivers/net/tun.c:689
tun_detach drivers/net/tun.c:705 [inline]
tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640
__fput+0x203/0x840 fs/file_table.c:280
task_work_run+0x129/0x1b0 kernel/task_work.c:185
exit_task_work include/linux/task_work.h:33 [inline]
do_exit+0x5ce/0x2200 kernel/exit.c:931
do_group_exit+0x144/0x310 kernel/exit.c:1046
__do_sys_exit_group kernel/exit.c:1057 [inline]
__se_sys_exit_group kernel/exit.c:1055 [inline]
__x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055
do_syscall_64+0x6c/0xd0
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7fe5e7b52479
Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.
RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0
R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270
The crash can be also be reproduced with the following (with a tc
recompiled to allow for sfq limits of 1):
tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s
../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1
ifconfig dummy0 up
ping -I dummy0 -f -c2 -W0.1 8.8.8.8
sleep 1
Scenario that triggers the crash:
* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1
* TBF dequeues: it peeks from SFQ which moves the packet to the
gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so
it schedules itself for later.
* the second packet is sent and TBF tries to queues it to SFQ. qdisc
qlen is now 2 and because the SFQ limit is 1 the packet is dropped
by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,
however q->tail is not NULL.
At this point, assuming no more packets are queued, when sch_dequeue
runs again it will decrement the qlen for the current empty slot
causing an underflow and the subsequent out of bounds access.
CVE-2024-57996
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
tpm: Change to kvalloc() in eventlog/acpi.c
The following failure was reported on HPE ProLiant D320:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)
[ 10.848132][ T1] ------------[ cut here ]------------
[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330
[ 10.862827][ T1] Modules linked in:
[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375
[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024
[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330
[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1
[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246
[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000
[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
The above transcript shows that ACPI pointed a 16 MiB buffer for the log
events because RSI maps to the 'order' parameter of __alloc_pages_noprof().
Address the bug by moving from devm_kmalloc() to devm_add_action() and
kvmalloc() and devm_add_action().
CVE-2024-58005
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
from l2cap_sock_new_connection_cb() and the error handling paths should
also be aware of it.
Seemingly a more elegant solution would be to swap bt_sock_alloc() and
l2cap_chan_create() calls since they are not interdependent to that moment
but then l2cap_chan_create() adds the soon to be deallocated and still
dummy-initialized channel to the global list accessible by many L2CAP
paths. The channel would be removed from the list in short period of time
but be a bit more straight-forward here and just check for NULL instead of
changing the order of function calls.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
CVE-2024-58009
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()
In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN()
instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access.
Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-58014
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX
Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which
leads to undefined behavior. To prevent this, cast 1 to u32 before
performing the shift, ensuring well-defined behavior.
This change explicitly avoids any potential overflow by ensuring that
the shift occurs on an unsigned 32-bit integer.
CVE-2024-58017
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table
The function atomctrl_get_smc_sclk_range_table() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to
retrieve SMU_Info table, it returns NULL which is later dereferenced.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In practice this should never happen as this code only gets called
on polaris chips and the vbios data table will always be present on
those chips.
CVE-2024-58052
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: fix memory leaks and invalid access at probe error path
Deinitialize at reverse order when probe fails.
When init_sw_vars fails, rtl_deinit_core should not be called, specially
now that it destroys the rtl_wq workqueue.
And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be
leaked.
Remove pci_set_drvdata call as it will already be cleaned up by the core
driver code and could lead to memory leaks too. cf. commit 8d450935ae7f
("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and
commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").
CVE-2024-58063
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
team: prevent adding a device which is already a team device lower
Prevent adding a device which is already a team device lower,
e.g. adding veth0 if vlan1 was already added and veth0 is a lower of
vlan1.
This is not useful in practice and can lead to recursive locking:
$ ip link add veth0 type veth peer name veth1
$ ip link set veth0 up
$ ip link set veth1 up
$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1
$ ip link add team0 type team
$ ip link set veth0.1 down
$ ip link set veth0.1 master team0
team0: Port device veth0.1 added
$ ip link set veth0 down
$ ip link set veth0 master team0
============================================
WARNING: possible recursive locking detected
6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
--------------------------------------------
ip/7684 is trying to acquire lock:
ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
but task is already holding lock:
ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(team->team_lock_key);
lock(team->team_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by ip/7684:
stack backtrace:
CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:122)
print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)
__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)
? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)
lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? lock_acquire (kernel/locking/lockdep.c:5822)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? fib_sync_up (net/ipv4/fib_semantics.c:2167)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
notifier_call_chain (kernel/notifier.c:85)
call_netdevice_notifiers_info (net/core/dev.c:1996)
__dev_notify_flags (net/core/dev.c:8993)
? __dev_change_flags (net/core/dev.c:8975)
dev_change_flags (net/core/dev.c:9027)
vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)
? br_device_event (net/bridge/br.c:143)
notifier_call_chain (kernel/notifier.c:85)
call_netdevice_notifiers_info (net/core/dev.c:1996)
dev_open (net/core/dev.c:1519 net/core/dev.c:1505)
team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)
? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)
do_set_master (net/core/rtnetlink.c:2917)
do_setlink.isra.0 (net/core/rtnetlink.c:3117)
CVE-2024-58071
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: remove unused check_buddy_priv
Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global
list of private data structures.
Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match
vendor version 2013.02.07") started adding the private data to that list at
probe time and added a hook, check_buddy_priv to find the private data from
a similar device.
However, that function was never used.
Besides, though there is a lock for that list, it is never used. And when
the probe fails, the private data is never removed from the list. This
would cause a second probe to access freed memory.
Remove the unused hook, structures and members, which will prevent the
potential race condition on the list and its corruption during a second
probe when probe fails.
CVE-2024-58072
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
Explicitly verify the target vCPU is fully online _prior_ to clamping the
index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will
generate '0', i.e. KVM will return vCPU0 instead of NULL.
In practice, the bug is unlikely to cause problems, as it will only come
into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
send interrupts to vCPU0 instead of dropping them on the floor.
However, returning vCPU0 when it shouldn't exist per online_vcpus is
problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
to insert into the xarray before publishing the vCPU to userspace (see
commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),
i.e. before vCPU creation is guaranteed to succeed.
As a result, incorrectly providing access to vCPU0 will trigger a
use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
bails out of vCPU creation due to an error and frees vCPU0. Commit
afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
in doing so introduced an unsolvable teardown conundrum. Preventing
accesses to vCPU0 before it's fully online will allow reverting commit
afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
CVE-2024-58083
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI/ASPM: Fix link state exit during switch upstream function removal
Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to
avoid use-after-free"), we would free the ASPM link only after the last
function on the bus pertaining to the given link was removed.
That was too late. If function 0 is removed before sibling function,
link->downstream would point to free'd memory after.
After above change, we freed the ASPM parent link state upon any function
removal on the bus pertaining to a given link.
That is too early. If the link is to a PCIe switch with MFD on the upstream
port, then removing functions other than 0 first would free a link which
still remains parent_link to the remaining downstream ports.
The resulting GPFs are especially frequent during hot-unplug, because
pciehp removes devices on the link bus in reverse order.
On that switch, function 0 is the virtual P2P bridge to the internal bus.
Free exactly when function 0 is removed -- before the parent link is
obsolete, but after all subordinate links are gone.
[kwilczynski: commit log]
CVE-2024-58093
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tls: separate no-async decryption request handling from async
If we're not doing async, the handling is much simpler. There's no
reference counting, we just need to wait for the completion to wake us
up and return its result.
We should preferably also use a separate crypto_wait. I'm not seeing a
UAF as I did in the past, I think aec7961916f3 ("tls: fix race between
async notify and socket close") took care of it.
This will make the next fix easier.
CVE-2024-58240
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
There is a MEDIUM severity vulnerability affecting CPython.
Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.
CVE-2024-6232
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.
CVE-2024-6345
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-setuptools-40.6.2-4.27.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-setuptools-40.6.2-4.27.1
important
There is a MEDIUM severity vulnerability affecting CPython.
The
email module didn't properly quote newlines for email headers when
serializing an email message allowing for header injection when an email
is serialized.
CVE-2024-6923
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an
ASN.1 Generalized Time field. If given an syntactically incorrect field, the
parser might end up using -1 for the length of the *time fraction*, leading to
a `strlen()` getting performed on a pointer to a heap buffer area that is not
(purposely) null terminated.
This flaw most likely leads to a crash, but can also lead to heap contents
getting returned to the application when
[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.
CVE-2024-7264
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
There is a LOW severity vulnerability affecting CPython, specifically the
'http.cookies' standard library module.
When parsing cookies that contained backslashes for quoted characters in
the cookie value, the parser would use an algorithm with quadratic
complexity, resulting in excess CPU resources being used while parsing the
value.
CVE-2024-7592
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.
CVE-2024-8006
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpcap1-1.8.1-10.9.1
moderate
When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.
CVE-2024-8096
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.
CVE-2024-8176
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.
CVE-2024-9287
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
When curl is asked to use HSTS, the expiry time for a subdomain might
overwrite a parent domain's cache entry, making it end sooner or later than
otherwise intended.
This affects curl using applications that enable HSTS and use URLs with the
insecure `HTTP://` scheme and perform transfers with hosts like
`x.example.com` as well as `example.com` where the first host is a subdomain
of the second host.
(The HSTS cache either needs to have been populated manually or there needs to
have been previous HTTPS accesses done as the cache needs to have entries for
the domains involved to trigger this problem.)
When `x.example.com` responds with `Strict-Transport-Security:` headers, this
bug can make the subdomain's expiry timeout *bleed over* and get set for the
parent domain `example.com` in curl's HSTS cache.
The result of a triggered bug is that HTTP accesses to `example.com` get
converted to HTTPS for a different period of time than what was asked for by
the origin server. If `example.com` for example stops supporting HTTPS at its
expiry time, curl might then fail to access `http://example.com` until the
(wrongly set) timeout expires. This bug can also expire the parent's entry
*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier
than otherwise intended.
CVE-2024-9681
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
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-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.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-v20260125-x86-64:glibc-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-i18ndata-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glibc-locale-2.22-114.40.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.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-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
curl's websocket code did not update the 32 bit mask pattern for each new
outgoing frame as the specification says. Instead it used a fixed mask that
persisted and was used throughout the entire connection.
A predictable mask pattern allows for a malicious server to induce traffic
between the two communicating parties that could be interpreted by an involved
proxy (configured or transparent) as genuine, real, HTTP traffic with content
and thereby poison its cache. That cached poisoned content could then be
served to all users of that proxy.
CVE-2025-10148
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The
malicious
rsync client requires at least read access to the remote rsync module in order to trigger the issue.
CVE-2025-10158
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:rsync-3.1.3-3.34.1
moderate
A flaw was found in Samba, in the front-end WINS hook handling: NetBIOS names from registration packets are passed to a shell without proper validation or escaping. Unsanitized NetBIOS name data from WINS registration packets are inserted into a shell command and executed by the Samba Active Directory Domain Controller's wins hook, allowing an unauthenticated network attacker to achieve remote command execution as the Samba process.
CVE-2025-10230
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:samba-client-libs-4.15.13+git.664.e8416d8d213-3.99.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:samba-libs-4.15.13+git.664.e8416d8d213-3.99.1
critical
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
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-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT <func:result> elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.
CVE-2025-11731
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxslt1-1.1.28-17.21.1
important
pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer. The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented. If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.
CVE-2025-11961
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpcap1-1.8.1-10.9.1
low
When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.
CVE-2025-12084
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
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-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
low
Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.
CVE-2025-13151
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libtasn1-4.9-3.19.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libtasn1-6-4.9-3.19.1
moderate
A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.
CVE-2025-13601
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
important
When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.
CVE-2025-13836
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues
CVE-2025-13837
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,
changing TLS options in one thread would inadvertently change them globally
and therefore possibly also affect other concurrently setup transfers.
Disabling certificate verification for a specific transfer could
unintentionally disable the feature for other threads as well.
CVE-2025-14017
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.
CVE-2025-14087
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
important
A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.
CVE-2025-14512
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
moderate
When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP,
POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new
target host.
CVE-2025-14524
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
When doing TLS related transfers with reused easy or multi handles and
altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally
reuse a CA store cached in memory for which the partial chain option was
reversed. Contrary to the user's wishes and expectations. This could make
libcurl find and accept a trust chain that it otherwise would not.
CVE-2025-14819
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
When doing SSH-based transfers using either SCP or SFTP, and setting the
known_hosts file, libcurl could still mistakenly accept connecting to hosts
*not present* in the specified file if they were added as recognized in the
libssh *global* known_hosts file.
CVE-2025-15079
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only
from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops'
(null-ptr-deref), e.g. when the current task is exiting, as spotted by
syzbot [1] using acct(2).
The per-netns structure can be obtained from the table->data using
container_of(), then the 'net' one can be retrieved from the listen
socket (if available).
CVE-2025-21635
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: clamp maximum hashtable size to INT_MAX
Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it
is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when
resizing hashtable because __GFP_NOWARN is unset. See:
0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")
Note: hashtable resize is only possible from init_netns.
CVE-2025-21648
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pfifo_tail_enqueue: Drop new packet when sch->limit == 0
Expected behaviour:
In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a
packet in scheduler's queue and decrease scheduler's qlen by one.
Then, pfifo_tail_enqueue() enqueue new packet and increase
scheduler's qlen by one. Finally, pfifo_tail_enqueue() return
`NET_XMIT_CN` status code.
Weird behaviour:
In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a
scheduler that has no packet, the 'drop a packet' step will do nothing.
This means the scheduler's qlen still has value equal 0.
Then, we continue to enqueue new packet and increase scheduler's qlen by
one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by
one and return `NET_XMIT_CN` status code.
The problem is:
Let's say we have two qdiscs: Qdisc_A and Qdisc_B.
- Qdisc_A's type must have '->graft()' function to create parent/child relationship.
Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.
- Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.
- Qdisc_B is configured to have `sch->limit == 0`.
- Qdisc_A is configured to route the enqueued's packet to Qdisc_B.
Enqueue packet through Qdisc_A will lead to:
- hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B)
- Qdisc_B->q.qlen += 1
- pfifo_tail_enqueue() return `NET_XMIT_CN`
- hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A.
The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1.
Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem.
This violate the design where parent's qlen should equal to the sum of its childrens'qlen.
Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.
CVE-2025-21702
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
netem: Update sch->q.qlen before qdisc_tree_reduce_backlog()
qdisc_tree_reduce_backlog() notifies parent qdisc only if child
qdisc becomes empty, therefore we need to reduce the backlog of the
child qdisc before calling it. Otherwise it would miss the opportunity
to call cops->qlen_notify(), in the case of DRR, it resulted in UAF
since DRR uses ->qlen_notify() to maintain its active list.
CVE-2025-21703
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
usb: cdc-acm: Check control transfer buffer size before access
If the first fragment is shorter than struct usb_cdc_notification, we can't
calculate an expected_size. Log an error and discard the notification
instead of reading lengths from memory outside the received data, which can
lead to memory corruption when the expected_size decreases between
fragments, causing `expected_size - acm->nb_index` to wrap.
This issue has been present since the beginning of git history; however,
it only leads to memory corruption since commit ea2583529cd1
("cdc-acm: reassemble fragmented notifications").
A mitigating factor is that acm_ctrl_irq() can only execute after userspace
has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will
do that automatically depending on the USB device's vendor/product IDs and
its other interfaces.
CVE-2025-21704
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: rtl8150: enable basic endpoint checking
Syzkaller reports [1] encountering a common issue of utilizing a wrong
usb endpoint type during URB submitting stage. This, in turn, triggers
a warning shown below.
For now, enable simple endpoint checking (specifically, bulk and
interrupt eps, testing control one is not essential) to mitigate
the issue with a view to do other related cosmetic changes later,
if they are necessary.
[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>
Modules linked in:
CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503
Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>
RSP: 0018:ffffc9000441f740 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9
RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001
RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c
FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733
__dev_open+0x2d4/0x4e0 net/core/dev.c:1474
__dev_change_flags+0x561/0x720 net/core/dev.c:8838
dev_change_flags+0x8f/0x160 net/core/dev.c:8910
devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177
inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003
sock_do_ioctl+0x116/0x280 net/socket.c:1222
sock_ioctl+0x22e/0x6c0 net/socket.c:1341
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fc04ef73d49
...
This change has not been tested on real hardware.
CVE-2025-21708
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nbd: don't allow reconnect after disconnect
Following process can cause nbd_config UAF:
1) grab nbd_config temporarily;
2) nbd_genl_disconnect() flush all recv_work() and release the
initial reference:
nbd_genl_disconnect
nbd_disconnect_and_put
nbd_disconnect
flush_workqueue(nbd->recv_workq)
if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))
nbd_config_put
-> due to step 1), reference is still not zero
3) nbd_genl_reconfigure() queue recv_work() again;
nbd_genl_reconfigure
config = nbd_get_config_unlocked(nbd)
if (!config)
-> succeed
if (!test_bit(NBD_RT_BOUND, ...))
-> succeed
nbd_reconnect_socket
queue_work(nbd->recv_workq, &args->work)
4) step 1) release the reference;
5) Finially, recv_work() will trigger UAF:
recv_work
nbd_config_put(nbd)
-> nbd_config is freed
atomic_dec(&config->recv_threads)
-> UAF
Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so
that nbd_genl_reconfigure() will fail.
CVE-2025-21731
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: Add bounds checking in nci_hci_create_pipe()
The "pipe" variable is a u8 which comes from the network. If it's more
than 127, then it results in memory corruption in the caller,
nci_hci_connect_gate().
CVE-2025-21735
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()
On removal of the device or unloading of the kernel module a potential NULL
pointer dereference occurs.
The following sequence deletes the interface:
brcmf_detach()
brcmf_remove_interface()
brcmf_del_if()
Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to
BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.
After brcmf_remove_interface() call the brcmf_proto_detach() function is
called providing the following sequence:
brcmf_detach()
brcmf_proto_detach()
brcmf_proto_msgbuf_detach()
brcmf_flowring_detach()
brcmf_msgbuf_delete_flowring()
brcmf_msgbuf_remove_flowring()
brcmf_flowring_delete()
brcmf_get_ifp()
brcmf_txfinalize()
Since brcmf_get_ip() can and actually will return NULL in this case the
call to brcmf_txfinalize() will result in a NULL pointer dereference inside
brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.
This will only happen if a flowring still has an skb.
Although the NULL pointer dereference has only been seen when trying to
update the tx statistic, all other uses of the ifp pointer have been
guarded as well with an early return if ifp is NULL.
CVE-2025-21744
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Check the return value of of_property_read_string_index()
Somewhen between 6.10 and 6.11 the driver started to crash on my
MacBookPro14,3. The property doesn't exist and 'tmp' remains
uninitialized, so we pass a random pointer to devm_kstrdup().
The crash I am getting looks like this:
BUG: unable to handle page fault for address: 00007f033c669379
PF: supervisor read access in kernel mode
PF: error_code(0x0001) - permissions violation
PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025
Oops: Oops: 0001 [#1] SMP PTI
CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1
Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024
RIP: 0010:strlen+0x4/0x30
Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc
RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202
RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001
RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379
RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a
R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8
R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30
FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x149/0x4c0
? raw_spin_rq_lock_nested+0xe/0x20
? sched_balance_newidle+0x22b/0x3c0
? update_load_avg+0x78/0x770
? exc_page_fault+0x6f/0x150
? asm_exc_page_fault+0x26/0x30
? __pfx_pci_conf1_write+0x10/0x10
? strlen+0x4/0x30
devm_kstrdup+0x25/0x70
brcmf_of_probe+0x273/0x350 [brcmfmac]
CVE-2025-21750
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: add RCU protection to mld_newpack()
mld_newpack() can be called without RTNL or RCU being held.
Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.
Instead use alloc_skb() and charge the net->ipv6.igmp_sk
socket under RCU protection.
CVE-2025-21758
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: extend RCU protection in igmp6_send()
igmp6_send() can be called without RTNL or RCU being held.
Extend RCU protection so that we can safely fetch the net pointer
and avoid a potential UAF.
Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.
Instead use alloc_skb() and charge the net->ipv6.igmp_sk
socket under RCU protection.
CVE-2025-21759
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ndisc: extend RCU protection in ndisc_send_skb()
ndisc_send_skb() can be called without RTNL or RCU held.
Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()
and avoid a potential UAF.
CVE-2025-21760
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arp: use RCU protection in arp_xmit()
arp_xmit() can be called without RTNL or RCU protection.
Use RCU protection to avoid potential UAF.
CVE-2025-21762
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
neighbour: use RCU protection in __neigh_notify()
__neigh_notify() can be called without RTNL or RCU protection.
Use RCU protection to avoid potential UAF.
CVE-2025-21763
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ndisc: use RCU protection in ndisc_alloc_skb()
ndisc_alloc_skb() can be called without RTNL or RCU being held.
Add RCU protection to avoid possible UAF.
CVE-2025-21764
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: use RCU protection in ip6_default_advmss()
ip6_default_advmss() needs rcu protection to make
sure the net structure it reads does not disappear.
CVE-2025-21765
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv4: use RCU protection in __ip_rt_update_pmtu()
__ip_rt_update_pmtu() must use RCU protection to make
sure the net structure it reads does not disappear.
CVE-2025-21766
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels
Some lwtunnels have a dst cache for post-transformation dst.
If the packet destination did not change we may end up recording
a reference to the lwtunnel in its own cache, and the lwtunnel
state will never be freed.
Discovered by the ioam6.sh test, kmemleak was recently fixed
to catch per-cpu memory leaks. I'm not sure if rpl and seg6
can actually hit this, but in principle I don't see why not.
CVE-2025-21768
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
partitions: mac: fix handling of bogus partition table
Fix several issues in partition probing:
- The bailout for a bad partoffset must use put_dev_sector(), since the
preceding read_part_sector() succeeded.
- If the partition table claims a silly sector size like 0xfff bytes
(which results in partition table entries straddling sector boundaries),
bail out instead of accessing out-of-bounds memory.
- We must not assume that the partition table contains proper NUL
termination - use strnlen() and strncmp() instead of strlen() and
strcmp().
CVE-2025-21772
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
USB: hub: Ignore non-compliant devices with too many configs or interfaces
Robert Morris created a test program which can cause
usb_hub_to_struct_hub() to dereference a NULL or inappropriate
pointer:
Oops: general protection fault, probably for non-canonical address
0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14
Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110
...
Call Trace:
<TASK>
? die_addr+0x31/0x80
? exc_general_protection+0x1b4/0x3c0
? asm_exc_general_protection+0x26/0x30
? usb_hub_adjust_deviceremovable+0x78/0x110
hub_probe+0x7c7/0xab0
usb_probe_interface+0x14b/0x350
really_probe+0xd0/0x2d0
? __pfx___device_attach_driver+0x10/0x10
__driver_probe_device+0x6e/0x110
driver_probe_device+0x1a/0x90
__device_attach_driver+0x7e/0xc0
bus_for_each_drv+0x7f/0xd0
__device_attach+0xaa/0x1a0
bus_probe_device+0x8b/0xa0
device_add+0x62e/0x810
usb_set_configuration+0x65d/0x990
usb_generic_driver_probe+0x4b/0x70
usb_probe_device+0x36/0xd0
The cause of this error is that the device has two interfaces, and the
hub driver binds to interface 1 instead of interface 0, which is where
usb_hub_to_struct_hub() looks.
We can prevent the problem from occurring by refusing to accept hub
devices that violate the USB spec by having more than one
configuration or interface.
CVE-2025-21776
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel
Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and
only if the local API is emulated/virtualized by KVM, and explicitly reject
said hypercalls if the local APIC is emulated in userspace, i.e. don't rely
on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.
Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if
Hyper-V enlightenments are exposed to the guest without an in-kernel local
APIC:
dump_stack+0xbe/0xfd
__kasan_report.cold+0x34/0x84
kasan_report+0x3a/0x50
__apic_accept_irq+0x3a/0x5c0
kvm_hv_send_ipi.isra.0+0x34e/0x820
kvm_hv_hypercall+0x8d9/0x9d0
kvm_emulate_hypercall+0x506/0x7e0
__vmx_handle_exit+0x283/0xb60
vmx_handle_exit+0x1d/0xd0
vcpu_enter_guest+0x16b0/0x24c0
vcpu_run+0xc0/0x550
kvm_arch_vcpu_ioctl_run+0x170/0x6d0
kvm_vcpu_ioctl+0x413/0xb20
__se_sys_ioctl+0x111/0x160
do_syscal1_64+0x30/0x40
entry_SYSCALL_64_after_hwframe+0x67/0xd1
Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode
can't be modified after vCPUs are created, i.e. if one vCPU has an
in-kernel local APIC, then all vCPUs have an in-kernel local APIC.
CVE-2025-21779
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix a oob in orangefs_debug_write
I got a syzbot report: slab-out-of-bounds Read in
orangefs_debug_write... several people suggested fixes,
I tested Al Viro's suggestion and made this patch.
CVE-2025-21782
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
The loop that detects/populates cache information already has a bounds
check on the array size but does not account for cache levels with
separate data/instructions cache. Fix this by incrementing the index
for any populated leaf (instead of any populated level).
CVE-2025-21785
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
team: better TEAM_OPTION_TYPE_STRING validation
syzbot reported following splat [1]
Make sure user-provided data contains one nul byte.
[1]
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline]
BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714
string_nocheck lib/vsprintf.c:633 [inline]
string+0x3ec/0x5f0 lib/vsprintf.c:714
vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843
__request_module+0x252/0x9f0 kernel/module/kmod.c:149
team_mode_get drivers/net/team/team_core.c:480 [inline]
team_change_mode drivers/net/team/team_core.c:607 [inline]
team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401
team_option_set drivers/net/team/team_core.c:375 [inline]
team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662
genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210
netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219
netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348
netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:718 [inline]
__sock_sendmsg+0x30f/0x380 net/socket.c:733
____sys_sendmsg+0x877/0xb60 net/socket.c:2573
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627
__sys_sendmsg net/socket.c:2659 [inline]
__do_sys_sendmsg net/socket.c:2664 [inline]
__se_sys_sendmsg net/socket.c:2662 [inline]
__x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662
x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2025-21787
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vrf: use RCU protection in l3mdev_l3_out()
l3mdev_l3_out() can be called without RCU being held:
raw_sendmsg()
ip_push_pending_frames()
ip_send_skb()
ip_local_out()
__ip_local_out()
l3mdev_ip_out()
Add rcu_read_lock() / rcu_read_unlock() pair to avoid
a potential UAF.
CVE-2025-21791
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clear acl_access/acl_default after releasing them
If getting acl_default fails, acl_access and acl_default will be released
simultaneously. However, acl_access will still retain a pointer pointing
to the released posix_acl, which will trigger a WARNING in
nfs3svc_release_getacl like this:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28
refcount_warn_saturate+0xb5/0x170
Modules linked in:
CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted
6.12.0-rc6-00079-g04ae226af01f-dirty #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb5/0x170
Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75
e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb
cd 0f b6 1d 8a3
RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380
RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56
R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001
R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0
FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
? refcount_warn_saturate+0xb5/0x170
? __warn+0xa5/0x140
? refcount_warn_saturate+0xb5/0x170
? report_bug+0x1b1/0x1e0
? handle_bug+0x53/0xa0
? exc_invalid_op+0x17/0x40
? asm_exc_invalid_op+0x1a/0x20
? tick_nohz_tick_stopped+0x1e/0x40
? refcount_warn_saturate+0xb5/0x170
? refcount_warn_saturate+0xb5/0x170
nfs3svc_release_getacl+0xc9/0xe0
svc_process_common+0x5db/0xb60
? __pfx_svc_process_common+0x10/0x10
? __rcu_read_unlock+0x69/0xa0
? __pfx_nfsd_dispatch+0x10/0x10
? svc_xprt_received+0xa1/0x120
? xdr_init_decode+0x11d/0x190
svc_process+0x2a7/0x330
svc_handle_xprt+0x69d/0x940
svc_recv+0x180/0x2d0
nfsd+0x168/0x200
? __pfx_nfsd+0x10/0x10
kthread+0x1a2/0x1e0
? kthread+0xf4/0x1e0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x60
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Kernel panic - not syncing: kernel: panic_on_warn set ...
Clear acl_access/acl_default after posix_acl_release is called to prevent
UAF from being triggered.
CVE-2025-21796
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix oops when unload drivers paralleling
When unload hclge driver, it tries to disable sriov first for each
ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at
the time, because it removes all the ae_dev nodes, and it may cause
oops.
But we can't simply use hnae3_common_lock for this. Because in the
process flow of pci_disable_sriov(), it will trigger the remove flow
of VF, which will also take hnae3_common_lock.
To fixes it, introduce a new mutex to protect the unload process.
CVE-2025-21802
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: let net.core.dev_weight always be non-zero
The following problem was encountered during stability test:
(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \
returned 1, exceeding its budget of 0.
------------[ cut here ]------------
list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \
next=ffff88905f746e40.
WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \
__list_add_valid_or_report+0xf3/0x130
CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+
RIP: 0010:__list_add_valid_or_report+0xf3/0x130
Call Trace:
? __warn+0xcd/0x250
? __list_add_valid_or_report+0xf3/0x130
enqueue_to_backlog+0x923/0x1070
netif_rx_internal+0x92/0x2b0
__netif_rx+0x15/0x170
loopback_xmit+0x2ef/0x450
dev_hard_start_xmit+0x103/0x490
__dev_queue_xmit+0xeac/0x1950
ip_finish_output2+0x6cc/0x1620
ip_output+0x161/0x270
ip_push_pending_frames+0x155/0x1a0
raw_sendmsg+0xe13/0x1550
__sys_sendto+0x3bf/0x4e0
__x64_sys_sendto+0xdc/0x1b0
do_syscall_64+0x5b/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The reproduction command is as follows:
sysctl -w net.core.dev_weight=0
ping 127.0.0.1
This is because when the napi's weight is set to 0, process_backlog() may
return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this
napi to be re-polled in net_rx_action() until __do_softirq() times out.
Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can
be retriggered in enqueue_to_backlog(), causing this issue.
Making the napi's weight always non-zero solves this problem.
Triggering this issue requires system-wide admin (setting is
not namespaced).
CVE-2025-21806
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ptp: Ensure info->enable callback is always set
The ioctl and sysfs handlers unconditionally call the ->enable callback.
Not all drivers implement that callback, leading to NULL dereferences.
Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.
Instead use a dummy callback if no better was specified by the driver.
CVE-2025-21814
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: omap: use threaded IRQ for LCD DMA
When using touchscreen and framebuffer, Nokia 770 crashes easily with:
BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000
Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd
CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2
Hardware name: Nokia 770
Call trace:
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x54/0x5c
dump_stack_lvl from __schedule_bug+0x50/0x70
__schedule_bug from __schedule+0x4d4/0x5bc
__schedule from schedule+0x34/0xa0
schedule from schedule_preempt_disabled+0xc/0x10
schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4
__mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4
clk_prepare_lock from clk_set_rate+0x18/0x154
clk_set_rate from sossi_read_data+0x4c/0x168
sossi_read_data from hwa742_read_reg+0x5c/0x8c
hwa742_read_reg from send_frame_handler+0xfc/0x300
send_frame_handler from process_pending_requests+0x74/0xd0
process_pending_requests from lcd_dma_irq_handler+0x50/0x74
lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130
__handle_irq_event_percpu from handle_irq_event+0x28/0x68
handle_irq_event from handle_level_irq+0x9c/0x170
handle_level_irq from generic_handle_domain_irq+0x2c/0x3c
generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c
omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c
generic_handle_arch_irq from call_with_stack+0x1c/0x24
call_with_stack from __irq_svc+0x94/0xa8
Exception stack(0xc5255da0 to 0xc5255de8)
5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248
5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94
5de0: 60000013 ffffffff
__irq_svc from clk_prepare_lock+0x4c/0xe4
clk_prepare_lock from clk_get_rate+0x10/0x74
clk_get_rate from uwire_setup_transfer+0x40/0x180
uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c
spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664
spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498
__spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8
__spi_sync from spi_sync+0x24/0x40
spi_sync from ads7846_halfd_read_state+0x5c/0x1c0
ads7846_halfd_read_state from ads7846_irq+0x58/0x348
ads7846_irq from irq_thread_fn+0x1c/0x78
irq_thread_fn from irq_thread+0x120/0x228
irq_thread from kthread+0xc8/0xe8
kthread from ret_from_fork+0x14/0x28
As a quick fix, switch to a threaded IRQ which provides a stable system.
CVE-2025-21821
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1
commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the
policy that all PCIe ports are allowed to use D3. When the system is
suspended if the port is not power manageable by the platform and won't be
used for wakeup via a PME this sets up the policy for these ports to go
into D3hot.
This policy generally makes sense from an OSPM perspective but it leads to
problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a
specific old BIOS. This manifests as a system hang.
On the affected Device + BIOS combination, add a quirk for the root port of
the problematic controller to ensure that these root ports are not put into
D3hot at suspend.
This patch is based on
https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com
but with the added condition both in the documentation and in the code to
apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only
the affected root ports.
CVE-2025-21831
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
acct: perform last write from workqueue
In [1] it was reported that the acct(2) system call can be used to
trigger NULL deref in cases where it is set to write to a file that
triggers an internal lookup. This can e.g., happen when pointing acc(2)
to /sys/power/resume. At the point the where the write to this file
happens the calling task has already exited and called exit_fs(). A
lookup will thus trigger a NULL-deref when accessing current->fs.
Reorganize the code so that the the final write happens from the
workqueue but with the caller's credentials. This preserves the
(strange) permission model and has almost no regression risk.
This api should stop to exist though.
CVE-2025-21846
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()
Add check for the return value of nfp_app_ctrl_msg_alloc() in
nfp_bpf_cmsg_alloc() to prevent null pointer dereference.
CVE-2025-21848
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
geneve: Fix use-after-free in geneve_find_dev().
syzkaller reported a use-after-free in geneve_find_dev() [0]
without repro.
geneve_configure() links struct geneve_dev.next to
net_generic(net, geneve_net_id)->geneve_list.
The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,
IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.
When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally
calls unregister_netdevice_queue() for each dev in the netns,
and later the dev is freed.
However, its geneve_dev.next is still linked to the backend UDP
socket netns.
Then, use-after-free will occur when another geneve dev is created
in the netns.
Let's call geneve_dellink() instead in geneve_destroy_tunnels().
[0]:
BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]
BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343
Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441
CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d
Hardware name: linux,dummy-virt (DT)
Call trace:
show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C)
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x16c/0x6f0 mm/kasan/report.c:489
kasan_report+0xc0/0x120 mm/kasan/report.c:602
__asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379
geneve_find_dev drivers/net/geneve.c:1295 [inline]
geneve_configure+0x234/0x858 drivers/net/geneve.c:1343
geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634
rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795
__rtnl_newlink net/core/rtnetlink.c:3906 [inline]
rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021
rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911
netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543
rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938
netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348
netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:713 [inline]
__sock_sendmsg net/socket.c:728 [inline]
____sys_sendmsg+0x410/0x6f8 net/socket.c:2568
___sys_sendmsg+0x178/0x1d8 net/socket.c:2622
__sys_sendmsg net/socket.c:2654 [inline]
__do_sys_sendmsg net/socket.c:2659 [inline]
__se_sys_sendmsg net/socket.c:2657 [inline]
__arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132
do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151
el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744
el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762
el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600
Allocated by task 13247:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x30/0x68 mm/kasan/common.c:68
kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4298 [inline]
__kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304
__kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645
alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470
rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604
rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780
__rtnl_newlink net/core/rtnetlink.c:3906 [inline]
rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021
rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911
netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543
rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938
netlink_unicast_kernel net/netlink/af_n
---truncated---
CVE-2025-21858
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: fix incorrect initialization order
Syzkaller reports the following bug:
BUG: spinlock bad magic on CPU#1, syz-executor.0/7995
lock: 0xffff88805303f3e0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x119/0x179 lib/dump_stack.c:118
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]
_raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159
reset_per_cpu_data+0xe6/0x240 [drop_monitor]
net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor]
genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497
genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348
netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916
sock_sendmsg_nosec net/socket.c:651 [inline]
__sock_sendmsg+0x157/0x190 net/socket.c:663
____sys_sendmsg+0x712/0x870 net/socket.c:2378
___sys_sendmsg+0xf8/0x170 net/socket.c:2432
__sys_sendmsg+0xea/0x1b0 net/socket.c:2461
do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x62/0xc7
RIP: 0033:0x7f3f9815aee9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9
RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007
RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768
If drop_monitor is built as a kernel module, syzkaller may have time
to send a netlink NET_DM_CMD_START message during the module loading.
This will call the net_dm_monitor_start() function that uses
a spinlock that has not yet been initialized.
To fix this, let's place resource initialization above the registration
of a generic netlink family.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller.
CVE-2025-21862
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().
Brad Spengler reported the list_del() corruption splat in
gtp_net_exit_batch_rtnl(). [0]
Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netns
dismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl()
to destroy devices in each netns as done in geneve and ip tunnels.
However, this could trigger ->dellink() twice for the same device during
->exit_batch_rtnl().
Say we have two netns A & B and gtp device B that resides in netns B but
whose UDP socket is in netns A.
1. cleanup_net() processes netns A and then B.
2. gtp_net_exit_batch_rtnl() finds the device B while iterating
netns A's gn->gtp_dev_list and calls ->dellink().
[ device B is not yet unlinked from netns B
as unregister_netdevice_many() has not been called. ]
3. gtp_net_exit_batch_rtnl() finds the device B while iterating
netns B's for_each_netdev() and calls ->dellink().
gtp_dellink() cleans up the device's hash table, unlinks the dev from
gn->gtp_dev_list, and calls unregister_netdevice_queue().
Basically, calling gtp_dellink() multiple times is fine unless
CONFIG_DEBUG_LIST is enabled.
Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and
delegate the destruction to default_device_exit_batch() as done
in bareudp.
[0]:
list_del corruption, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04)
kernel BUG at lib/list_debug.c:58!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1
Tainted: [T]=RANDSTRUCT
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: netns cleanup_net
RIP: 0010:[<ffffffff84947381>] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58
Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60
RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283
RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054
RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000
RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32
R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4
R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08
RBX: kasan shadow of 0x0
RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554
RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58
RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71
RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]
RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ]
R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ]
R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ]
R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object]
FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0
Stack:
0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00
ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005
0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d
Call Trace:
<TASK>
[<ffffffff8a0c360d>] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28
[<ffffffff8a0c360d>] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28
[<ffffffff8a0c360d>] list_del include/linux/list.h:262 [inl
---truncated---
CVE-2025-21865
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tee: optee: Fix supplicant wait loop
OP-TEE supplicant is a user-space daemon and it's possible for it
be hung or crashed or killed in the middle of processing an OP-TEE
RPC call. It becomes more complicated when there is incorrect shutdown
ordering of the supplicant process vs the OP-TEE client application which
can eventually lead to system hang-up waiting for the closure of the
client application.
Allow the client process waiting in kernel for supplicant response to
be killed rather than indefinitely waiting in an unkillable state. Also,
a normal uninterruptible wait should not have resulted in the hung-task
watchdog getting triggered, but the endless loop would.
This fixes issues observed during system reboot/shutdown when supplicant
got hung for some reason or gets crashed/killed which lead to client
getting hung in an unkillable state. It in turn lead to system being in
hung up state requiring hard power off/on to recover.
CVE-2025-21871
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usbnet: gl620a: fix endpoint checking in genelink_bind()
Syzbot reports [1] a warning in usb_submit_urb() triggered by
inconsistencies between expected and actually present endpoints
in gl620a driver. Since genelink_bind() does not properly
verify whether specified eps are in fact provided by the device,
in this case, an artificially manufactured one, one may get a
mismatch.
Fix the issue by resorting to a usbnet utility function
usbnet_get_endpoints(), usually reserved for this very problem.
Check for endpoints and return early before proceeding further if
any are missing.
[1] Syzbot report:
usb 5-1: Manufacturer: syz
usb 5-1: SerialNumber: syz
usb 5-1: config 0 descriptor??
gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...
------------[ cut here ]------------
usb 5-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503
Modules linked in:
CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: mld mld_ifc_work
RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503
...
Call Trace:
<TASK>
usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467
__netdev_start_xmit include/linux/netdevice.h:5002 [inline]
netdev_start_xmit include/linux/netdevice.h:5011 [inline]
xmit_one net/core/dev.c:3590 [inline]
dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606
sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343
__dev_xmit_skb net/core/dev.c:3827 [inline]
__dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400
dev_queue_xmit include/linux/netdevice.h:3168 [inline]
neigh_resolve_output net/core/neighbour.c:1514 [inline]
neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494
neigh_output include/net/neighbour.h:539 [inline]
ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141
__ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247
dst_output include/net/dst.h:450 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819
mld_send_cr net/ipv6/mcast.c:2120 [inline]
mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651
process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229
process_scheduled_works kernel/workqueue.c:3310 [inline]
worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391
kthread+0x2c1/0x3a0 kernel/kthread.c:389
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
CVE-2025-21877
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
uprobes: Reject the shared zeropage in uprobe_write_opcode()
We triggered the following crash in syzkaller tests:
BUG: Bad page state in process syz.7.38 pfn:1eff3
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3
flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)
raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000
raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
bad_page+0x69/0xf0
free_unref_page_prepare+0x401/0x500
free_unref_page+0x6d/0x1b0
uprobe_write_opcode+0x460/0x8e0
install_breakpoint.part.0+0x51/0x80
register_for_each_vma+0x1d9/0x2b0
__uprobe_register+0x245/0x300
bpf_uprobe_multi_link_attach+0x29b/0x4f0
link_create+0x1e2/0x280
__sys_bpf+0x75f/0xac0
__x64_sys_bpf+0x1a/0x30
do_syscall_64+0x56/0x100
entry_SYSCALL_64_after_hwframe+0x78/0xe2
BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1
The following syzkaller test case can be used to reproduce:
r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8)
write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10)
r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0)
mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)
r5 = userfaultfd(0x80801)
ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20})
r6 = userfaultfd(0x80801)
ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140))
ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})
ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}})
r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)
bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)
The cause is that zero pfn is set to the PTE without increasing the RSS
count in mfill_atomic_pte_zeropage() and the refcount of zero folio does
not increase accordingly. Then, the operation on the same pfn is performed
in uprobe_write_opcode()->__replace_page() to unconditional decrease the
RSS count and old_folio's refcount.
Therefore, two bugs are introduced:
1. The RSS count is incorrect, when process exit, the check_mm() report
error "Bad rss-count".
2. The reserved folio (zero folio) is freed when folio->refcount is zero,
then free_pages_prepare->free_page_is_bad() report error
"Bad page state".
There is more, the following warning could also theoretically be triggered:
__replace_page()
-> ...
-> folio_remove_rmap_pte()
-> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)
Considering that uprobe hit on the zero folio is a very rare case, just
reject zero old folio immediately after get_user_page_vma_remote().
[ mingo: Cleaned up the changelog ]
CVE-2025-21881
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: ensure network headers are in skb linear part
syzbot found that ipvlan_process_v6_outbound() was assuming
the IPv6 network header isis present in skb->head [1]
Add the needed pskb_network_may_pull() calls for both
IPv4 and IPv6 handlers.
[1]
BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
__ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
ipv6_addr_type include/net/ipv6.h:555 [inline]
ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline]
ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651
ip6_route_output include/net/ip6_route.h:93 [inline]
ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476
ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline]
ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline]
ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline]
ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671
ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223
__netdev_start_xmit include/linux/netdevice.h:5150 [inline]
netdev_start_xmit include/linux/netdevice.h:5159 [inline]
xmit_one net/core/dev.c:3735 [inline]
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751
sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343
qdisc_restart net/sched/sch_generic.c:408 [inline]
__qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416
qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127
net_tx_action+0x78b/0x940 net/core/dev.c:5484
handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
__do_softirq+0x14/0x1a kernel/softirq.c:595
do_softirq+0x9a/0x100 kernel/softirq.c:462
__local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
__dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611
dev_queue_xmit include/linux/netdevice.h:3311 [inline]
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3132 [inline]
packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164
sock_sendmsg_nosec net/socket.c:718 [inline]
CVE-2025-21891
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Avoid potential division by zero in function_stat_show()
Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}
produce zero and skip stddev computation in that case.
For now don't care about rec->counter * rec->counter overflow because
rec->time * rec->time overflow will likely happen earlier.
CVE-2025-21898
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: reject cooked mode if it is set along with other flags
It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE
flags simultaneously on the same monitor interface from the userspace. This
causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit
set because the monitor interface is in the cooked state and it takes
precedence over all other states. When the interface is then being deleted
the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing
that bit.
Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with
other flags.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-21909
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: regulatory: improve invalid hints checking
Syzbot keeps reporting an issue [1] that occurs when erroneous symbols
sent from userspace get through into user_alpha2[] via
regulatory_hint_user() call. Such invalid regulatory hints should be
rejected.
While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:
reject invalid hints") looks to be enough to deter these very cases,
there is a way to get around it due to 2 reasons.
1) The way isalpha() works, symbols other than latin lower and
upper letters may be used to determine a country/domain.
For instance, greek letters will also be considered upper/lower
letters and for such characters isalpha() will return true as well.
However, ISO-3166-1 alpha2 codes should only hold latin
characters.
2) While processing a user regulatory request, between
reg_process_hint_user() and regulatory_hint_user() there happens to
be a call to queue_regulatory_request() which modifies letters in
request->alpha2[] with toupper(). This works fine for latin symbols,
less so for weird letter characters from the second part of _ctype[].
Syzbot triggers a warning in is_user_regdom_saved() by first sending
over an unexpected non-latin letter that gets malformed by toupper()
into a character that ends up failing isalpha() check.
Prevent this by enhancing is_an_alpha2() to ensure that incoming
symbols are latin letters and nothing else.
[1] Syzbot report:
------------[ cut here ]------------
Unexpected user alpha2: A�
WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]
WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]
WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516
Modules linked in:
CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: events_power_efficient crda_timeout_work
RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]
RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]
RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516
...
Call Trace:
<TASK>
crda_timeout_work+0x27/0x50 net/wireless/reg.c:542
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f2/0x390 kernel/kthread.c:389
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
CVE-2025-21910
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: atm: cxacru: fix a flaw in existing endpoint checks
Syzbot once again identified a flaw in usb endpoint checking, see [1].
This time the issue stems from a commit authored by me (2eabb655a968
("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")).
While using usb_find_common_endpoints() may usually be enough to
discard devices with wrong endpoints, in this case one needs more
than just finding and identifying the sufficient number of endpoints
of correct types - one needs to check the endpoint's address as well.
Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind,
switch the endpoint verification approach to usb_check_XXX_endpoints()
instead to fix incomplete ep testing.
[1] Syzbot report:
usb 5-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
Call Trace:
<TASK>
cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649
cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline]
cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223
usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058
cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377
usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396
really_probe+0x2b9/0xad0 drivers/base/dd.c:658
__driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800
driver_probe_device+0x50/0x430 drivers/base/dd.c:830
...
CVE-2025-21916
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vlan: enforce underlying device type
Currently, VLAN devices can be created on top of non-ethernet devices.
Besides the fact that it doesn't make much sense, this also causes a
bug which leaks the address of a kernel function to usermode.
When creating a VLAN device, we initialize GARP (garp_init_applicant)
and MRP (mrp_init_applicant) for the underlying device.
As part of the initialization process, we add the multicast address of
each applicant to the underlying device, by calling dev_mc_add.
__dev_mc_add uses dev->addr_len to determine the length of the new
multicast address.
This causes an out-of-bounds read if dev->addr_len is greater than 6,
since the multicast addresses provided by GARP and MRP are only 6
bytes long.
This behaviour can be reproduced using the following commands:
ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo
ip l set up dev gretest
ip link add link gretest name vlantest type vlan id 100
Then, the following command will display the address of garp_pdu_rcv:
ip maddr show | grep 01:80:c2:00:00:21
Fix the bug by enforcing the type of the underlying device during VLAN
device initialization.
CVE-2025-21920
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the
ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program:
'''
struct bpf_program fp;
pcap_t *handle;
handle = pcap_open_dead(DLT_PPP_PPPD, 65535);
pcap_compile(handle, &fp, "ip and outbound", 0, 0);
bpf_dump(&fp, 1);
'''
Its output is:
'''
(000) ldh [2]
(001) jeq #0x21 jt 2 jf 5
(002) ldb [0]
(003) jeq #0x1 jt 4 jf 5
(004) ret #65535
(005) ret #0
'''
Wen can find similar code at the following link:
https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680
The maintainer of this code repository is also the original maintainer
of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the
'Protocol' field to determine if it's an IP packet. Then it read the first
byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized
in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be
used, so it's not a problem. However, for carefully crafted BPF programs,
such as those generated by syzkaller [2], which start reading from offset
0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791
[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000
CVE-2025-21922
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: gso: fix ownership in __udp_gso_segment
In __udp_gso_segment the skb destructor is removed before segmenting the
skb but the socket reference is kept as-is. This is an issue if the
original skb is later orphaned as we can hit the following bug:
kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan)
RIP: 0010:ip_rcv_core+0x8b2/0xca0
Call Trace:
ip_rcv+0xab/0x6e0
__netif_receive_skb_one_core+0x168/0x1b0
process_backlog+0x384/0x1100
__napi_poll.constprop.0+0xa1/0x370
net_rx_action+0x925/0xe50
The above can happen following a sequence of events when using
OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an
OVS_ACTION_ATTR_OUTPUT action:
1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb
goes through queue_gso_packets and then __udp_gso_segment, where its
destructor is removed.
2. The segments' data are copied and sent to userspace.
3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the
same original skb is sent to its path.
4. If it later hits skb_orphan, we hit the bug.
Fix this by also removing the reference to the socket in
__udp_gso_segment.
CVE-2025-21926
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()
nvme_tcp_recv_pdu() doesn't check the validity of the header length.
When header digests are enabled, a target might send a packet with an
invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()
to access memory outside the allocated area and cause memory corruptions
by overwriting it with the calculated digest.
Fix this by rejecting packets with an unexpected header length.
CVE-2025-21927
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()
The system can experience a random crash a few minutes after the driver is
removed. This issue occurs due to improper handling of memory freeing in
the ishtp_hid_remove() function.
The function currently frees the `driver_data` directly within the loop
that destroys the HID devices, which can lead to accessing freed memory.
Specifically, `hid_destroy_device()` uses `driver_data` when it calls
`hid_ishtp_set_feature()` to power off the sensor, so freeing
`driver_data` beforehand can result in accessing invalid memory.
This patch resolves the issue by storing the `driver_data` in a temporary
variable before calling `hid_destroy_device()`, and then freeing the
`driver_data` after the device is destroyed.
CVE-2025-21928
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio
Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to
be offlined) add page poison checks in do_migrate_range in order to make
offline hwpoisoned page possible by introducing isolate_lru_page and
try_to_unmap for hwpoisoned page. However folio lock must be held before
calling try_to_unmap. Add it to fix this problem.
Warning will be produced if folio is not locked during unmap:
------------[ cut here ]------------
kernel BUG at ./include/linux/swapops.h:400!
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41
Tainted: [W]=WARN
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : try_to_unmap_one+0xb08/0xd3c
lr : try_to_unmap_one+0x3dc/0xd3c
Call trace:
try_to_unmap_one+0xb08/0xd3c (P)
try_to_unmap_one+0x3dc/0xd3c (L)
rmap_walk_anon+0xdc/0x1f8
rmap_walk+0x3c/0x58
try_to_unmap+0x88/0x90
unmap_poisoned_folio+0x30/0xa8
do_migrate_range+0x4a0/0x568
offline_pages+0x5a4/0x670
memory_block_action+0x17c/0x374
memory_subsys_offline+0x3c/0x78
device_offline+0xa4/0xd0
state_store+0x8c/0xf0
dev_attr_store+0x18/0x2c
sysfs_kf_write+0x44/0x54
kernfs_fop_write_iter+0x118/0x1a8
vfs_write+0x3a8/0x4bc
ksys_write+0x6c/0xf8
__arm64_sys_write+0x1c/0x28
invoke_syscall+0x44/0x100
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x30/0xd0
el0t_64_sync_handler+0xc8/0xcc
el0t_64_sync+0x198/0x19c
Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)
---[ end trace 0000000000000000 ]---
CVE-2025-21931
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix an API misues when rio_add_net() fails
rio_add_net() calls device_register() and fails when device_register()
fails. Thus, put_device() should be used rather than kfree(). Add
"mport->net = NULL;" to avoid a use after free issue.
CVE-2025-21934
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
rapidio: add check for rio_add_net() in rio_scan_alloc_net()
The return value of rio_add_net() should be checked. If it fails,
put_device() should be called to free the memory and give up the reference
initialized in rio_add_net().
CVE-2025-21935
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params
Null pointer dereference issue could occur when pipe_ctx->plane_state
is null. The fix adds a check to ensure 'pipe_ctx->plane_state' is not
null before accessing. This prevents a null pointer dereference.
Found by code review.
(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)
CVE-2025-21941
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: appleir: Fix potential NULL dereference at raw event handle
Syzkaller reports a NULL pointer dereference issue in input_event().
BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]
BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]
BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395
Read of size 8 at addr 0000000000000028 by task syz-executor199/2949
CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
kasan_report+0xd9/0x110 mm/kasan/report.c:602
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
instrument_atomic_read include/linux/instrumented.h:68 [inline]
_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
is_event_supported drivers/input/input.c:67 [inline]
input_event+0x42/0xa0 drivers/input/input.c:395
input_report_key include/linux/input.h:439 [inline]
key_down drivers/hid/hid-appleir.c:159 [inline]
appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232
__hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111
hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484
__usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734
dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993
__run_hrtimer kernel/time/hrtimer.c:1739 [inline]
__hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803
hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820
handle_softirqs+0x206/0x8d0 kernel/softirq.c:561
__do_softirq kernel/softirq.c:595 [inline]
invoke_softirq kernel/softirq.c:435 [inline]
__irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662
irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
__mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185
add_timer+0x62/0x90 kernel/time/timer.c:1295
schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98
usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645
usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784
hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl fs/ioctl.c:892 [inline]
__x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
This happens due to the malformed report items sent by the emulated device
which results in a report, that has no fields, being added to the report list.
Due to this appleir_input_configured() is never called, hidinput_connect()
fails which results in the HID_CLAIMED_INPUT flag is not being set. However,
it does not make appleir_probe() fail and lets the event callback to be
called without the associated input device.
Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook
early if the driver didn't claim any input_dev for some reason. Moreover,
some other hid drivers accessing input_dev in their event callbacks do have
similar checks, too.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-21948
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Assign normalized_pix_clk when color depth = 14
[WHY & HOW]
A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397
calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the
display_color_depth == COLOR_DEPTH_141414 is not handled. This is
observed in Radeon RX 6600 XT.
It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.
Also fixes the indentation in get_norm_pix_clk.
(cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)
CVE-2025-21956
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla1280: Fix kernel oops when debug level > 2
A null dereference or oops exception will eventually occur when qla1280.c
driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I
think its clear from the code that the intention here is sg_dma_len(s) not
length of sg_next(s) when printing the debug info.
CVE-2025-21957
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix integer overflow while processing acdirmax mount option
User-provided mount parameter acdirmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-21963
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix integer overflow while processing acregmax mount option
User-provided mount parameter acregmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-21964
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd
After the hci sync command releases l2cap_conn, the hci receive data work
queue references the released l2cap_conn when sending to the upper layer.
Add hci dev lock to the hci receive data work queue to synchronize the two.
[1]
BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954
Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837
CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: hci1 hci_rx_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x169/0x550 mm/kasan/report.c:489
kasan_report+0x143/0x180 mm/kasan/report.c:602
l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline]
l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954
l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline]
l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline]
l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817
hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline]
hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Allocated by task 5837:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329
kmalloc_noprof include/linux/slab.h:901 [inline]
kzalloc_noprof include/linux/slab.h:1037 [inline]
l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860
l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239
hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]
hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726
hci_event_func net/bluetooth/hci_event.c:7473 [inline]
hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525
hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Freed by task 54:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2353 [inline]
slab_free mm/slub.c:4613 [inline]
kfree+0x196/0x430 mm/slub.c:4761
l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235
hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]
hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266
hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603
hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr
---truncated---
CVE-2025-21969
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Prevent creation of classes with TC_H_ROOT
The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination
condition when traversing up the qdisc tree to update parent backlog
counters. However, if a class is created with classid TC_H_ROOT, the
traversal terminates prematurely at this class instead of reaching the
actual root qdisc, causing parent statistics to be incorrectly maintained.
In case of DRR, this could lead to a crash as reported by Mingi Cho.
Prevent the creation of any Qdisc class with classid TC_H_ROOT
(0xFFFFFFFF) across all qdisc types, as suggested by Jamal.
CVE-2025-21971
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
fbdev: hyperv_fb: Allow graceful removal of framebuffer
When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to
release the framebuffer forcefully. If this framebuffer is in use it
produce the following WARN and hence this framebuffer is never released.
[ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40
< snip >
[ 44.111289] Call Trace:
[ 44.111290] <TASK>
[ 44.111291] ? show_regs+0x6c/0x80
[ 44.111295] ? __warn+0x8d/0x150
[ 44.111298] ? framebuffer_release+0x2c/0x40
[ 44.111300] ? report_bug+0x182/0x1b0
[ 44.111303] ? handle_bug+0x6e/0xb0
[ 44.111306] ? exc_invalid_op+0x18/0x80
[ 44.111308] ? asm_exc_invalid_op+0x1b/0x20
[ 44.111311] ? framebuffer_release+0x2c/0x40
[ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb]
[ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus]
[ 44.111323] device_remove+0x40/0x80
[ 44.111325] device_release_driver_internal+0x20b/0x270
[ 44.111327] ? bus_find_device+0xb3/0xf0
Fix this by moving the release of framebuffer and assosiated memory
to fb_ops.fb_destroy function, so that framebuffer framework handles
it gracefully.
While we fix this, also replace manual registrations/unregistration of
framebuffer with devm_register_framebuffer.
CVE-2025-21976
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()
When performing an iSCSI boot using IPv6, iscsistart still reads the
/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix
length is 64, this causes the shift exponent to become negative,
triggering a UBSAN warning. As the concept of a subnet mask does not
apply to IPv6, the value is set to ~0 to suppress the warning message.
CVE-2025-21993
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()
On the off chance that command stream passed from userspace via
ioctl() call to radeon_vce_cs_parse() is weirdly crafted and
first command to execute is to encode (case 0x03000001), the function
in question will attempt to call radeon_vce_cs_reloc() with size
argument that has not been properly initialized. Specifically, 'size'
will point to 'tmp' variable before the latter had a chance to be
assigned any value.
Play it safe and init 'tmp' with 0, thus ensuring that
radeon_vce_cs_reloc() will catch an early error in cases like these.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)
CVE-2025-21996
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: atm: fix use after free in lec_send()
The ->send() operation frees skb so save the length before calling
->send() to avoid a use after free.
CVE-2025-22004
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix error code in chan_alloc_skb_cb()
The chan_alloc_skb_cb() function is supposed to return error pointers on
error. Returning NULL will lead to a NULL dereference.
CVE-2025-22007
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
regulator: check that dummy regulator has been probed before using it
Due to asynchronous driver probing there is a chance that the dummy
regulator hasn't already been probed when first accessing it.
CVE-2025-22008
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix soft lockup during bt pages loop
Driver runs a for-loop when allocating bt pages and mapping them with
buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,
it may require a considerable loop count. This will lead to soft lockup:
watchdog: BUG: soft lockup - CPU#27 stuck for 22s!
...
Call trace:
hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]
hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]
hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]
alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]
hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x118/0x290
watchdog: BUG: soft lockup - CPU#35 stuck for 23s!
...
Call trace:
hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]
mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]
hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]
alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]
hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]
ib_uverbs_reg_mr+0x120/0x2bc
Add a cond_resched() to fix soft lockup during these loops. In order not
to affect the allocation performance of normal-size buffer, set the loop
count of a 100GB MR as the threshold to call cond_resched().
CVE-2025-22010
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger
Null Pointer Dereference Vulnerability if both entry and
holding_time are NULL. Because there is only for the situation
where entry is NULL and holding_time exists, it can be passed
when both entry and holding_time are NULL. If these are NULL,
the entry will be passd to eg_cache_put() as parameter and
it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725] <TASK>
[ 3.326927] ? die_addr+0x3c/0xa0
[ 3.327330] ? exc_general_protection+0x161/0x2a0
[ 3.327662] ? asm_exc_general_protection+0x26/0x30
[ 3.328214] ? vprintk_emit+0x15e/0x420
[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470
[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470
[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10
[ 3.329664] ? console_unlock+0x107/0x1d0
[ 3.329946] ? __pfx_console_unlock+0x10/0x10
[ 3.330283] ? do_syscall_64+0xa6/0x1a0
[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10
[ 3.331395] ? down_trylock+0x52/0x80
[ 3.331703] ? vprintk_emit+0x15e/0x420
[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10
[ 3.332279] ? down_trylock+0x52/0x80
[ 3.332527] ? _printk+0xbf/0x100
[ 3.332762] ? __pfx__printk+0x10/0x10
[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0
[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10
[ 3.333614] msg_from_mpoad+0x1185/0x2750
[ 3.333893] ? __build_skb_around+0x27b/0x3a0
[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10
[ 3.334501] ? __alloc_skb+0x1c0/0x310
[ 3.334809] ? __pfx___alloc_skb+0x10/0x10
[ 3.335283] ? _raw_spin_lock+0xe0/0xe0
[ 3.335632] ? finish_wait+0x8d/0x1e0
[ 3.335975] vcc_sendmsg+0x684/0xba0
[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10
[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10
[ 3.337056] ? fdget+0x176/0x3e0
[ 3.337348] __sys_sendto+0x4a2/0x510
[ 3.337663] ? __pfx___sys_sendto+0x10/0x10
[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[ 3.338364] ? sock_ioctl+0x1bb/0x5a0
[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20
[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10
[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10
[ 3.339727] ? selinux_file_ioctl+0xa4/0x260
[ 3.340166] __x64_sys_sendto+0xe0/0x1c0
[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140
[ 3.340898] do_syscall_64+0xa6/0x1a0
[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 3.341533] RIP: 0033:0x44a380
[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[
---truncated---
CVE-2025-22018
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to
restore the original 5-tuple in case of SNAT, to be able to find the
right socket (if any). Then socket_match() can correctly check whether
the socket was transparent.
However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this
conntrack lookup, making xt_socket fail to match on the socket when the
packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as
pods' addresses are in the fd00::/8 ULA subnet and need to be replaced
with the node's external address. Cilium leverages Envoy to enforce L7
policies, and Envoy uses transparent sockets. Cilium inserts an iptables
prerouting rule that matches on `-m socket --transparent` and redirects
the packets to localhost, but it fails to match SNATed IPv6 packets due
to that missing conntrack lookup.
CVE-2025-22021
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop
bug, one without) were seen to cause IOMMU faults after some Missed
Service Errors. Faulting address is immediately after a transfer ring
segment and patched dynamic debug messages revealed that the MSE was
received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0
[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]
[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to
the HC. Below, it reports MSE in segment at ff1e8000, plows through a
zero-filled page at ff1e9000 and starts reporting events for TRBs in
page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.
[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to
Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to
random buffers of pending TDs on other endpoints (either IN or OUT),
other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it
caused by the above? I don't know, but it may have been. The disk
was working without any other issues and generated PCIe traffic to
starve the NEC of upstream BW and trigger those MSEs. The two HCs
shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd
[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00
[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting
the chain bit of Link TRBs on isochronous rings. Other ancient HCs are
known which also expect the bit to be set and they ignore Link TRBs if
it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports
tens of MSEs per second and runs into the bug within seconds. Chaining
Link TRBs allows the same workload to run for many minutes, many times.
No ne
---truncated---
CVE-2025-22022
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: put dl_stid if fail to queue dl_recall
Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we
increment the reference count of dl_stid.
We expect that after the corresponding work_struct is processed, the
reference count of dl_stid will be decremented through the callback
function nfsd4_cb_recall_release.
However, if the call to nfsd4_run_cb fails, the incremented reference
count of dl_stid will not be decremented correspondingly, leading to the
following nfs4_stid leak:
unreferenced object 0xffff88812067b578 (size 344):
comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s)
hex dump (first 32 bytes):
01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........
00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N..
backtrace:
kmem_cache_alloc+0x4b9/0x700
nfsd4_process_open1+0x34/0x300
nfsd4_open+0x2d1/0x9d0
nfsd4_proc_compound+0x7a2/0xe30
nfsd_dispatch+0x241/0x3e0
svc_process_common+0x5d3/0xcc0
svc_process+0x2a3/0x320
nfsd+0x180/0x2e0
kthread+0x199/0x1d0
ret_from_fork+0x30/0x50
ret_from_fork_asm+0x1b/0x30
unreferenced object 0xffff8881499f4d28 (size 368):
comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I....
30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... .......
backtrace:
kmem_cache_alloc+0x4b9/0x700
nfs4_alloc_stid+0x29/0x210
alloc_init_deleg+0x92/0x2e0
nfs4_set_delegation+0x284/0xc00
nfs4_open_delegation+0x216/0x3f0
nfsd4_process_open2+0x2b3/0xee0
nfsd4_open+0x770/0x9d0
nfsd4_proc_compound+0x7a2/0xe30
nfsd_dispatch+0x241/0x3e0
svc_process_common+0x5d3/0xcc0
svc_process+0x2a3/0x320
nfsd+0x180/0x2e0
kthread+0x199/0x1d0
ret_from_fork+0x30/0x50
ret_from_fork_asm+0x1b/0x30
Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if
fail to queue dl_recall.
CVE-2025-22025
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: streamzap: fix race between device disconnection and urb callback
Syzkaller has reported a general protection fault at function
ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer
dereference of dev->raw pointer, even though it is checked for NULL in
the same function, which means there is a race condition. It occurs due
to the incorrect order of actions in the streamzap_disconnect() function:
rc_unregister_device() is called before usb_kill_urb(). The dev->raw
pointer is freed and set to NULL in rc_unregister_device(), and only
after that usb_kill_urb() waits for in-progress requests to finish.
If rc_unregister_device() is called while streamzap_callback() handler is
not finished, this can lead to accessing freed resources. Thus
rc_unregister_device() should be called after usb_kill_urb().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-22027
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2025-22029
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free in print_graph_function_flags during tracer switching
Kairui reported a UAF issue in print_graph_function_flags() during
ftrace stress testing [1]. This issue can be reproduced if puting a
'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),
and executing the following script:
$ echo function_graph > current_tracer
$ cat trace > /dev/null &
$ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point
$ echo timerlat > current_tracer
The root cause lies in the two calls to print_graph_function_flags
within print_trace_line during each s_show():
* One through 'iter->trace->print_line()';
* Another through 'event->funcs->trace()', which is hidden in
print_trace_fmt() before print_trace_line returns.
Tracer switching only updates the former, while the latter continues
to use the print_line function of the old tracer, which in the script
above is print_graph_function_flags.
Moreover, when switching from the 'function_graph' tracer to the
'timerlat' tracer, s_start only calls graph_trace_close of the
'function_graph' tracer to free 'iter->private', but does not set
it to NULL. This provides an opportunity for 'event->funcs->trace()'
to use an invalid 'iter->private'.
To fix this issue, set 'iter->private' to NULL immediately after
freeing it in graph_trace_close(), ensuring that an invalid pointer
is not passed to other tracers. Additionally, clean up the unnecessary
'iter->private = NULL' during each 'cat trace' when using wakeup and
irqsoff tracers.
[1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
CVE-2025-22035
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usbnet:fix NPE during rx_complete
Missing usbnet_going_away Check in Critical Path.
The usb_submit_urb function lacks a usbnet_going_away
validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data
fails to be queued.
Subsequent processes:
(e.g., rx_complete -> defer_bh -> __skb_unlink(skb, list))
attempt to access skb->next, triggering a NULL pointer
dereference (Kernel Panic).
CVE-2025-22050
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ibmveth: make veth_pool_store stop hanging
v2:
- Created a single error handling unlock and exit in veth_pool_store
- Greatly expanded commit message with previous explanatory-only text
Summary: Use rtnl_mutex to synchronize veth_pool_store with itself,
ibmveth_close and ibmveth_open, preventing multiple calls in a row to
napi_disable.
Background: Two (or more) threads could call veth_pool_store through
writing to /sys/devices/vio/30000002/pool*/*. You can do this easily
with a little shell script. This causes a hang.
I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new
kernel. I ran this test again and saw:
Setting pool0/active to 0
Setting pool1/active to 1
[ 73.911067][ T4365] ibmveth 30000002 eth0: close starting
Setting pool1/active to 1
Setting pool1/active to 0
[ 73.911367][ T4366] ibmveth 30000002 eth0: close starting
[ 73.916056][ T4365] ibmveth 30000002 eth0: close complete
[ 73.916064][ T4365] ibmveth 30000002 eth0: open starting
[ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.
[ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8
[ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000
[ 243.683852][ T123] Call Trace:
[ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)
[ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0
[ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0
[ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210
[ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50
[ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0
[ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60
[ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc
[ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270
[ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0
[ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0
[ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650
[ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150
[ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340
[ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec
...
[ 243.684087][ T123] Showing all locks held in the system:
[ 243.684095][ T123] 1 lock held by khungtaskd/123:
[ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248
[ 243.684114][ T123] 4 locks held by stress.sh/4365:
[ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0
[ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0
[ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60
[ 243.684166][ T123] 5 locks held by stress.sh/4366:
[ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[ 243.
---truncated---
CVE-2025-22053
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fix geneve_opt length integer overflow
struct geneve_opt uses 5 bit length for each single option, which
means every vary size option should be smaller than 128 bytes.
However, all current related Netlink policies cannot promise this
length condition and the attacker can exploit a exact 128-byte size
option to *fake* a zero length option and confuse the parsing logic,
further achieve heap out-of-bounds read.
One example crash log is like below:
[ 3.905425] ==================================================================
[ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0
[ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177
[ 3.906646]
[ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1
[ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[ 3.907784] Call Trace:
[ 3.907925] <TASK>
[ 3.908048] dump_stack_lvl+0x44/0x5c
[ 3.908258] print_report+0x184/0x4be
[ 3.909151] kasan_report+0xc5/0x100
[ 3.909539] kasan_check_range+0xf3/0x1a0
[ 3.909794] memcpy+0x1f/0x60
[ 3.909968] nla_put+0xa9/0xe0
[ 3.910147] tunnel_key_dump+0x945/0xba0
[ 3.911536] tcf_action_dump_1+0x1c1/0x340
[ 3.912436] tcf_action_dump+0x101/0x180
[ 3.912689] tcf_exts_dump+0x164/0x1e0
[ 3.912905] fw_dump+0x18b/0x2d0
[ 3.913483] tcf_fill_node+0x2ee/0x460
[ 3.914778] tfilter_notify+0xf4/0x180
[ 3.915208] tc_new_tfilter+0xd51/0x10d0
[ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560
[ 3.919118] netlink_rcv_skb+0xcd/0x200
[ 3.919787] netlink_unicast+0x395/0x530
[ 3.921032] netlink_sendmsg+0x3d0/0x6d0
[ 3.921987] __sock_sendmsg+0x99/0xa0
[ 3.922220] __sys_sendto+0x1b7/0x240
[ 3.922682] __x64_sys_sendto+0x72/0x90
[ 3.922906] do_syscall_64+0x5e/0x90
[ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 3.924122] RIP: 0033:0x7e83eab84407
[ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf
[ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407
[ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003
[ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c
[ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0
[ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8
Fix these issues by enforing correct length condition in related
policies.
CVE-2025-22055
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix memory accounting leak.
Matt Dowling reported a weird UDP memory usage issue.
Under normal operation, the UDP memory usage reported in /proc/net/sockstat
remains close to zero. However, it occasionally spiked to 524,288 pages
and never dropped. Moreover, the value doubled when the application was
terminated. Finally, it caused intermittent packet drops.
We can reproduce the issue with the script below [0]:
1. /proc/net/sockstat reports 0 pages
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 0
2. Run the script till the report reaches 524,288
# python3 test.py & sleep 5
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT
3. Kill the socket and confirm the number never drops
# pkill python3 && sleep 5
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 524288
4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()
# python3 test.py & sleep 1 && pkill python3
5. The number doubles
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 1048577
The application set INT_MAX to SO_RCVBUF, which triggered an integer
overflow in udp_rmem_release().
When a socket is close()d, udp_destruct_common() purges its receive
queue and sums up skb->truesize in the queue. This total is calculated
and stored in a local unsigned integer variable.
The total size is then passed to udp_rmem_release() to adjust memory
accounting. However, because the function takes a signed integer
argument, the total size can wrap around, causing an overflow.
Then, the released amount is calculated as follows:
1) Add size to sk->sk_forward_alloc.
2) Round down sk->sk_forward_alloc to the nearest lower multiple of
PAGE_SIZE and assign it to amount.
3) Subtract amount from sk->sk_forward_alloc.
4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().
When the issue occurred, the total in udp_destruct_common() was 2147484480
(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().
At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and
2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't
see a warning in inet_sock_destruct(). However, udp_memory_allocated
ends up doubling at 4).
Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for
memory_allocated"), memory usage no longer doubles immediately after
a socket is close()d because __sk_mem_reduce_allocated() caches the
amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP
socket receives a packet, the subtraction takes effect, causing UDP
memory usage to double.
This issue makes further memory allocation fail once the socket's
sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet
drops.
To prevent this issue, let's use unsigned int for the calculation and
call sk_forward_alloc_add() only once for the small delta.
Note that first_packet_length() also potentially has the same problem.
[0]:
from socket import *
SO_RCVBUFFORCE = 33
INT_MAX = (2 ** 31) - 1
s = socket(AF_INET, SOCK_DGRAM)
s.bind(('', 0))
s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)
c = socket(AF_INET, SOCK_DGRAM)
c.connect(s.getsockname())
data = b'a' * 100
while True:
c.send(data)
CVE-2025-22058
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: Prevent parser TCAM memory corruption
Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM
information, from concurrent modifications.
Both the TCAM and SRAM tables are indirectly accessed by configuring
an index register that selects the row to read or write to. This means
that operations must be atomic in order to, e.g., avoid spreading
writes across multiple rows. Since the shadow SRAM array is used to
find free rows in the hardware table, it must also be protected in
order to avoid TOCTOU errors where multiple cores allocate the same
row.
This issue was detected in a situation where `mvpp2_set_rx_mode()` ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
`rx_classifier_drops` counter.
CVE-2025-22060
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlbl_conn_setattr(), addr->sa_family is used
to determine the function behavior. If sk is an IPv4 socket,
but the connect function is called with an IPv6 address,
the function calipso_sock_setattr() is triggered.
Inside this function, the following code is executed:
sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a
null pointer dereference.
This patch fixes the issue by checking if inet6_sk(sk)
returns a NULL pointer before accessing pinet6.
CVE-2025-22063
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from
the radix tree again we check if the next cqe QP is identical to
the one we already have.
The bug however is that we are checking if the QP is identical by
checking the QP number inside the CQE against the QP number inside the
mlx5_ib_qp, but that's wrong since the QP number from the CQE is from
FW so it should be matched against mlx5_core_qp which is our FW QP
number.
Otherwise we could use the wrong QP when handling a CQE which could
cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are
the only QPs in our driver whereas the QP number inside mlx5_ib_qp
doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP
CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21
RSP: 0018:ffff88810511bd60 EFLAGS: 00010046
RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a
RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10
R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000
R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0
FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0
Call Trace:
<TASK>
? __die+0x20/0x60
? page_fault_oops+0x150/0x3e0
? exc_page_fault+0x74/0x130
? asm_exc_page_fault+0x22/0x30
? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
__ib_process_cq+0x5a/0x150 [ib_core]
ib_cq_poll_work+0x31/0x90 [ib_core]
process_one_work+0x169/0x320
worker_thread+0x288/0x3a0
? work_busy+0xb0/0xb0
kthread+0xd7/0x1f0
? kthreads_online_cpu+0x130/0x130
? kthreads_online_cpu+0x130/0x130
ret_from_fork+0x2d/0x50
? kthreads_online_cpu+0x130/0x130
ret_from_fork_asm+0x11/0x20
</TASK>
CVE-2025-22086
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Use kernel helpers for hex dumps
Previously, when the driver was printing hex dumps, the buffer was cast
to an 8 byte long and printed using string formatters. If the buffer
size was not a multiple of 8 then a read buffer overflow was possible.
Therefore, create a new ibmvnic function that loops over a buffer and
calls hex_dump_to_buffer instead.
This patch address KASAN reports like the one below:
ibmvnic 30000003 env3: Login Buffer:
ibmvnic 30000003 env3: 01000000af000000
<...>
ibmvnic 30000003 env3: 2e6d62692e736261
ibmvnic 30000003 env3: 65050003006d6f63
==================================================================
BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]
Read of size 8 at addr c0000001331a9aa8 by task ip/17681
<...>
Allocated by task 17681:
<...>
ibmvnic_login+0x2f0/0xffc [ibmvnic]
ibmvnic_open+0x148/0x308 [ibmvnic]
__dev_open+0x1ac/0x304
<...>
The buggy address is located 168 bytes inside of
allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)
<...>
=================================================================
ibmvnic 30000003 env3: 000000000033766e
CVE-2025-22104
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.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-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.
CVE-2025-22868
important
FreeType 2.8.1 has a signed integer overflow in cf2_doFlex in cff/cf2intrp.c.
CVE-2025-23022
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libfreetype6-2.6.3-7.24.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dlm: prevent NPD when writing a positive value to event_done
do_uevent returns the value written to event_done. In case it is a
positive value, new_lockspace would undo all the work, and lockspace
would not be set. __dlm_new_lockspace, however, would treat that
positive value as a success due to commit 8511a2728ab8 ("dlm: fix use
count with multiple joins").
Down the line, device_create_lockspace would pass that NULL lockspace to
dlm_find_lockspace_local, leading to a NULL pointer dereference.
Treating such positive values as successes prevents the problem. Given
this has been broken for so long, this is unlikely to break userspace
expectations.
CVE-2025-23131
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: Add NULL check for adev
Not all devices have an ACPI companion fwnode, so adev might be NULL.
This is similar to the commit cd2fd6eab480
("platform/x86: int3472: Check for adev == NULL").
Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in int3402_thermal_probe().
Note, under the same directory, int3400_thermal_probe() has such a
check.
[ rjw: Subject edit, added Fixes: ]
CVE-2025-23136
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses
Acquire a lock on kvm->srcu when userspace is getting MP state to handle a
rather extreme edge case where "accepting" APIC events, i.e. processing
pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU
is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP
state will trigger a nested VM-Exit by way of ->check_nested_events(), and
emuating the nested VM-Exit can access guest memory.
The splat was originally hit by syzkaller on a Google-internal kernel, and
reproduced on an upstream kernel by hacking the triple_fault_event_test
selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a
memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.
=============================
WARNING: suspicious RCU usage
6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
-----------------------------
include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by triple_fault_ev/1256:
#0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]
stack backtrace:
CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:
<TASK>
dump_stack_lvl+0x7f/0x90
lockdep_rcu_suspicious+0x144/0x190
kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]
kvm_vcpu_read_guest+0x3e/0x90 [kvm]
read_and_check_msr_entry+0x2e/0x180 [kvm_intel]
__nested_vmx_vmexit+0x550/0xde0 [kvm_intel]
kvm_check_nested_events+0x1b/0x30 [kvm]
kvm_apic_accept_events+0x33/0x100 [kvm]
kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]
kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]
__x64_sys_ioctl+0x8b/0xb0
do_syscall_64+0x6c/0x170
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
CVE-2025-23141
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tpm: do not start chip while suspended
Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can
lead to a spurious tpm_chip_start() call:
[35985.503771] i2c i2c-1: Transfer while suspended
[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810
[35985.503802] Modules linked in:
[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f
[35985.503814] Tainted: [W]=WARN
[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023
[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810
[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5
[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246
[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000
[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001
[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820
[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120
[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000
[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0
[35985.503855] Call Trace:
[35985.503859] <TASK>
[35985.503863] ? __warn+0xd4/0x260
[35985.503868] ? __i2c_transfer+0xbe/0x810
[35985.503874] ? report_bug+0xf3/0x210
[35985.503882] ? handle_bug+0x63/0xb0
[35985.503887] ? exc_invalid_op+0x16/0x50
[35985.503892] ? asm_exc_invalid_op+0x16/0x20
[35985.503904] ? __i2c_transfer+0xbe/0x810
[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0
[35985.503920] tpm_cr50_i2c_read+0x8e/0x120
[35985.503928] tpm_cr50_request_locality+0x75/0x170
[35985.503935] tpm_chip_start+0x116/0x160
[35985.503942] tpm_try_get_ops+0x57/0x90
[35985.503948] tpm_find_get_ops+0x26/0xd0
[35985.503955] tpm_get_random+0x2d/0x80
Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless
TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in
such a failure case.
CVE-2025-23149
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was
caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
__asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154
make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351
ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455
ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796
ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431
vfs_symlink+0x137/0x2e0 fs/namei.c:4615
do_symlinkat+0x222/0x3a0 fs/namei.c:4641
__do_sys_symlink fs/namei.c:4662 [inline]
__se_sys_symlink fs/namei.c:4660 [inline]
__x64_sys_symlink+0x7a/0x90 fs/namei.c:4660
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) {
/* is more than half of this entry in 2nd half of the block? */
if (size + map[i].size/2 > blocksize/2)
break;
size += map[i].size;
move++;
}
'i' in this case could go down to -1, in which case sum of active entries
wouldn't exceed half the block size, but previous behaviour would also do
split in half if sum would exceed at the very last block, which in case of
having too many long name files in a single block could lead to
out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-23150
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type
The access to the PCI config space via pci_ops::read and pci_ops::write is
a low-level hardware access. The functions can be accessed with disabled
interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this
purpose.
A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be
acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in
the same context as the pci_lock.
Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with
interrupts disabled.
This was reported as:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
Call Trace:
rt_spin_lock+0x4e/0x130
vmd_pci_read+0x8d/0x100 [vmd]
pci_user_read_config_byte+0x6f/0xe0
pci_read_config+0xfe/0x290
sysfs_kf_bin_read+0x68/0x90
[bigeasy: reword commit message]
Tested-off-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
[kwilczynski: commit log]
[bhelgaas: add back report info from
https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]
CVE-2025-23161
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: vlan: don't propagate flags on open
With the device instance lock, there is now a possibility of a deadlock:
[ 1.211455] ============================================
[ 1.211571] WARNING: possible recursive locking detected
[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted
[ 1.211823] --------------------------------------------
[ 1.211936] ip/184 is trying to acquire lock:
[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0
[ 1.212207]
[ 1.212207] but task is already holding lock:
[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0
[ 1.212487]
[ 1.212487] other info that might help us debug this:
[ 1.212626] Possible unsafe locking scenario:
[ 1.212626]
[ 1.212751] CPU0
[ 1.212815] ----
[ 1.212871] lock(&dev->lock);
[ 1.212944] lock(&dev->lock);
[ 1.213016]
[ 1.213016] *** DEADLOCK ***
[ 1.213016]
[ 1.213143] May be due to missing lock nesting notation
[ 1.213143]
[ 1.213294] 3 locks held by ip/184:
[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0
[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0
[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0
[ 1.213895]
[ 1.213895] stack backtrace:
[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5
[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
[ 1.213994] Call Trace:
[ 1.213995] <TASK>
[ 1.213996] dump_stack_lvl+0x8e/0xd0
[ 1.214000] print_deadlock_bug+0x28b/0x2a0
[ 1.214020] lock_acquire+0xea/0x2a0
[ 1.214027] __mutex_lock+0xbf/0xd40
[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI
[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev
[ 1.214042] __dev_open+0x145/0x270
[ 1.214046] __dev_change_flags+0xb0/0x1e0
[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev
[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info
[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0
[ 1.214058] notifier_call_chain+0x78/0x120
[ 1.214062] netif_open+0x6d/0x90
[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0
[ 1.214066] bond_enslave+0x64c/0x1230
[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0
[ 1.214077] do_setlink+0x516/0x13b0
[ 1.214094] rtnl_newlink+0xaba/0xb80
[ 1.214132] rtnetlink_rcv_msg+0x440/0x490
[ 1.214144] netlink_rcv_skb+0xeb/0x120
[ 1.214150] netlink_unicast+0x1f9/0x320
[ 1.214153] netlink_sendmsg+0x346/0x3f0
[ 1.214157] __sock_sendmsg+0x86/0xb0
[ 1.214160] ____sys_sendmsg+0x1c8/0x220
[ 1.214164] ___sys_sendmsg+0x28f/0x2d0
[ 1.214179] __x64_sys_sendmsg+0xef/0x140
[ 1.214184] do_syscall_64+0xec/0x1d0
[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 1.214191] RIP: 0033:0x7f2d1b4a7e56
Device setup:
netdevsim0 (down)
^ ^
bond netdevsim1.100@netdevsim1 allmulticast=on (down)
When we enslave the lower device (netdevsim0) which has a vlan, we
propagate vlan's allmuti/promisc flags during ndo_open. This causes
(re)locking on of the real_dev.
Propagate allmulti/promisc on flags change, not on the open. There
is a slight semantics change that vlans that are down now propagate
the flags, but this seems unlikely to result in the real issues.
Reproducer:
echo 0 1 > /sys/bus/netdevsim/new_device
dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*)
dev=$(echo $dev_path | rev | cut -d/ -f1 | rev)
ip link set dev $dev name netdevsim0
ip link set dev netdevsim0 up
ip link add link netdevsim0 name netdevsim0.100 type vlan id 100
ip link set dev netdevsim0.100 allm
---truncated---
CVE-2025-23163
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
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-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash.
CVE-2025-24528
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
moderate
numbers.c in libxslt before 1.1.43 has a use-after-free because, in nested XPath evaluations, an XPath context node can be modified but never restored. This is related to xsltNumberFormatGetValue, xsltEvalXPathPredicate, xsltEvalXPathStringNs, and xsltComputeSortResultInternal.
CVE-2025-24855
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxslt1-1.1.28-17.21.1
important
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-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
moderate
A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
CVE-2025-2588
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:augeas-1.10.1-4.6.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:augeas-lenses-1.10.1-4.6.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libaugeas0-1.10.1-4.6.1
low
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-v20260125-x86-64:openssh-7.2p2-81.34.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-v20260125-x86-64:libX11-6-1.6.2-12.36.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-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-v20260125-x86-64:libxml2-2-2.9.4-46.93.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-v20260125-x86-64:libfreetype6-2.6.3-7.24.1
important
In SQLite 3.44.0 through 3.49.0 before 3.49.1, the concat_ws() SQL function can cause memory to be written beyond the end of a malloc-allocated buffer. If the separator argument is attacker-controlled and has a large string (e.g., 2MB or more), an integer overflow occurs in calculating the size of the result buffer, and thus malloc may not allocate enough memory.
CVE-2025-29087
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libsqlite3-0-3.50.2-9.41.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sqlite3-tcl-3.50.2-9.41.1
moderate
In SQLite 3.49.0 before 3.49.1, certain argument values to sqlite3_db_config (in the C-language API) can cause a denial of service (application crash). An sz*nBig multiplication is not cast to a 64-bit integer, and consequently some memory allocations may be incorrect.
CVE-2025-29088
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libsqlite3-0-3.50.2-9.41.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sqlite3-tcl-3.50.2-9.41.1
moderate
Vim, a text editor, is vulnerable to potential data loss with zip.vim and special crafted zip files in versions prior to 9.1.1198. The impact is medium because a user must be made to view such an archive with Vim and then press 'x' on such a strange filename. The issue has been fixed as of Vim patch v9.1.1198.
CVE-2025-29768
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.
CVE-2025-32414
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
moderate
In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.
CVE-2025-32415
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
low
Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.
CVE-2025-32462
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sudo-1.8.27-4.54.1
important
A heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system.
CVE-2025-32990
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgnutls30-3.4.17-8.20.1
moderate
A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.
CVE-2025-3576
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-1.16.3-46.21.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:krb5-client-1.16.3-46.21.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: ppp: Add bound checking for skb data on ppp_sync_txmung
Ensure we have enough data in linear buffer from skb before accessing
initial bytes. This prevents potential out-of-bounds accesses
when processing short packets.
When ppp_sync_txmung receives an incoming package with an empty
payload:
(remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header)
$18 = {
type = 0x1,
ver = 0x1,
code = 0x0,
sid = 0x2,
length = 0x0,
tag = 0xffff8880371cdb96
}
from the skb struct (trimmed)
tail = 0x16,
end = 0x140,
head = 0xffff88803346f400 "4",
data = 0xffff88803346f416 ":\377",
truesize = 0x380,
len = 0x0,
data_len = 0x0,
mac_len = 0xe,
hdr_len = 0x0,
it is not safe to access data[2].
[pabeni@redhat.com: fixed subj typo]
CVE-2025-37749
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: move the limit validation
It is not sufficient to directly validate the limit on the data that
the user passes as it can be updated based on how the other parameters
are changed.
Move the check at the end of the configuration update process to also
catch scenarios where the limit is indirectly updated, for example
with the following configurations:
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
This fixes the following syzkaller reported crash:
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6
index 65535 is out of range for type 'struct sfq_head[128]'
CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:231 [inline]
__ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429
sfq_link net/sched/sch_sfq.c:203 [inline]
sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231
sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493
sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518
qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035
tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339
qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035
dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311
netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]
dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375
CVE-2025-37752
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then
run into all sort of unexpected corner cases. I have a vague
recollection of Eric pointing this out to us a long time ago.
Supporting disconnect is really hard, for one thing if offload
is enabled we'd need to wait for all packets to be _acked_.
Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp,
but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486
Call Trace:
<TASK>
tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363
tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043
inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678
sock_recvmsg_nosec net/socket.c:1023 [inline]
sock_recvmsg+0x109/0x280 net/socket.c:1045
__sys_recvfrom+0x202/0x380 net/socket.c:2237
CVE-2025-37756
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix memory leak in tipc_link_xmit
In case the backlog transmit queue for system-importance messages is overloaded,
tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to
memory leak and failure when a skb is allocated.
This commit fixes this issue by purging the skb list before tipc_link_xmit()
returns.
CVE-2025-37757
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
isofs: Prevent the use of too small fid
syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]
The handle_bytes value passed in by the reproducing program is equal to 12.
In handle_to_path(), only 12 bytes of memory are allocated for the structure
file_handle->f_handle member, which causes an out-of-bounds access when
accessing the member parent_block of the structure isofs_fid in isofs,
because accessing parent_block requires at least 16 bytes of f_handle.
Here, fh_len is used to indirectly confirm that the value of handle_bytes
is greater than 3 before accessing parent_block.
[1]
BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183
Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466
CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call trace:
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0x198/0x550 mm/kasan/report.c:521
kasan_report+0xd8/0x138 mm/kasan/report.c:634
__asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380
isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183
exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523
do_handle_to_path+0xa0/0x198 fs/fhandle.c:257
handle_to_path fs/fhandle.c:385 [inline]
do_handle_open+0x8cc/0xb8c fs/fhandle.c:403
__do_sys_open_by_handle_at fs/fhandle.c:443 [inline]
__se_sys_open_by_handle_at fs/fhandle.c:434 [inline]
__arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744
el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Allocated by task 6466:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x40/0x78 mm/kasan/common.c:68
kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4294 [inline]
__kmalloc_noprof+0x32c/0x54c mm/slub.c:4306
kmalloc_noprof include/linux/slab.h:905 [inline]
handle_to_path fs/fhandle.c:357 [inline]
do_handle_open+0x5a4/0xb8c fs/fhandle.c:403
__do_sys_open_by_handle_at fs/fhandle.c:443 [inline]
__se_sys_open_by_handle_at fs/fhandle.c:434 [inline]
__arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744
el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
CVE-2025-37780
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i2c: cros-ec-tunnel: defer probe if parent EC is not present
When i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent
device will not be found, leading to NULL pointer dereference.
That can also be reproduced by unbinding the controller driver and then
loading i2c-cros-ec-tunnel module (or binding the device).
[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058
[ 271.998215] #PF: supervisor read access in kernel mode
[ 272.003351] #PF: error_code(0x0000) - not-present page
[ 272.008485] PGD 0 P4D 0
[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI
[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5
[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC
[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021
[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel]
[ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9
[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282
[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000
[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00
[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000
[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000
[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10
[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000
[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0
[ 272.129155] Call Trace:
[ 272.131606] <TASK>
[ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110
[ 272.137985] platform_probe+0x69/0xa0
[ 272.141652] really_probe+0x152/0x310
[ 272.145318] __driver_probe_device+0x77/0x110
[ 272.149678] driver_probe_device+0x1e/0x190
[ 272.153864] __driver_attach+0x10b/0x1e0
[ 272.157790] ? driver_attach+0x20/0x20
[ 272.161542] bus_for_each_dev+0x107/0x150
[ 272.165553] bus_add_driver+0x15d/0x270
[ 272.169392] driver_register+0x65/0x110
[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698]
[ 272.182617] do_one_initcall+0x110/0x350
[ 272.186543] ? security_kernfs_init_security+0x49/0xd0
[ 272.191682] ? __kernfs_new_node+0x1b9/0x240
[ 272.195954] ? security_kernfs_init_security+0x49/0xd0
[ 272.201093] ? __kernfs_new_node+0x1b9/0x240
[ 272.205365] ? kernfs_link_sibling+0x105/0x130
[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0
[ 272.214773] ? kernfs_activate+0x57/0x70
[ 272.218699] ? kernfs_add_one+0x118/0x160
[ 272.222710] ? __kernfs_create_file+0x71/0xa0
[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110
[ 272.232033] ? internal_create_group+0x453/0x4a0
[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0
[ 272.241355] ? __free_frozen_pages+0x1dc/0x420
[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0
[ 272.250505] ? load_module+0x1509/0x16f0
[ 272.254431] do_init_module+0x60/0x230
[ 272.258181] __se_sys_finit_module+0x27a/0x370
[ 272.262627] do_syscall_64+0x6a/0xf0
[ 272.266206] ? do_syscall_64+0x76/0xf0
[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90
[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ 272.279887] RIP: 0033:0x7b9309168d39
[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8
[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000
---truncated---
CVE-2025-37781
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2025-37782
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir
entry with rec_len == block size results in out-of-bounds read (later
on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.'
and '..' as directory entries in the first data block. It first loads
the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry()
and then uses its rec_len member to compute the location of '..' dir
entry (in ext4_next_entry). It assumes the '..' dir entry fits into the
same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the
sanity checks (it is considered the last directory entry in the data
block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the
memory slot allocated to the data block. The following call to
ext4_check_dir_entry() on new value of de then dereferences this pointer
which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir
entries that reach the end of data block. Make sure to ignore the phony
dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another
structure was recently freed from the slot past the bound, but it is
really an OOB read.
This issue was found by syzkaller tool.
Call Trace:
[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710
[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375
[ 38.595158]
[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1
[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 38.595304] Call Trace:
[ 38.595308] <TASK>
[ 38.595311] dump_stack_lvl+0xa7/0xd0
[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0
[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710
[ 38.595349] print_report+0xaa/0x250
[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710
[ 38.595368] ? kasan_addr_to_slab+0x9/0x90
[ 38.595378] kasan_report+0xab/0xe0
[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710
[ 38.595400] __ext4_check_dir_entry+0x67e/0x710
[ 38.595410] ext4_empty_dir+0x465/0x990
[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10
[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10
[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0
[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10
[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10
[ 38.595478] ? down_write+0xdb/0x140
[ 38.595487] ? __pfx_down_write+0x10/0x10
[ 38.595497] ext4_rmdir+0xee/0x140
[ 38.595506] vfs_rmdir+0x209/0x670
[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190
[ 38.595529] do_rmdir+0x363/0x3c0
[ 38.595537] ? __pfx_do_rmdir+0x10/0x10
[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0
[ 38.595561] __x64_sys_unlinkat+0xf0/0x130
[ 38.595570] do_syscall_64+0x5b/0x180
[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVE-2025-37785
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix nested key length validation in the set() action
It's not safe to access nla_len(ovs_key) if the data is smaller than
the netlink header. Check that the attribute is OK first.
CVE-2025-37789
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Purge vif txq in ieee80211_do_stop()
After ieee80211_do_stop() SKB from vif's txq could still be processed.
Indeed another concurrent vif schedule_and_wake_txq call could cause
those packets to be dequeued (see ieee80211_handle_wake_tx_queue())
without checking the sdata current state.
Because vif.drv_priv is now cleared in this function, this could lead to
driver crash.
For example in ath12k, ahvif is store in vif.drv_priv. Thus if
ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be
NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to
trigger the NULL deref below.
Unable to handle kernel paging request at virtual address dfffffc000000001
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
batman_adv: bat0: Interface deactivated: brbh1337
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[dfffffc000000001] address between user and kernel address ranges
Internal error: Oops: 0000000096000004 [#1] SMP
CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114
Hardware name: HW (DT)
pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]
lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]
sp : ffffffc086ace450
x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4
x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e
x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0
x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958
x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8
x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03
x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40
x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0
x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008
Call trace:
ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)
ieee80211_handle_wake_tx_queue+0x16c/0x260
ieee80211_queue_skb+0xeec/0x1d20
ieee80211_tx+0x200/0x2c8
ieee80211_xmit+0x22c/0x338
__ieee80211_subif_start_xmit+0x7e8/0xc60
ieee80211_subif_start_xmit+0xc4/0xee0
__ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0
ieee80211_subif_start_xmit_8023+0x124/0x488
dev_hard_start_xmit+0x160/0x5a8
__dev_queue_xmit+0x6f8/0x3120
br_dev_queue_push_xmit+0x120/0x4a8
__br_forward+0xe4/0x2b0
deliver_clone+0x5c/0xd0
br_flood+0x398/0x580
br_dev_xmit+0x454/0x9f8
dev_hard_start_xmit+0x160/0x5a8
__dev_queue_xmit+0x6f8/0x3120
ip6_finish_output2+0xc28/0x1b60
__ip6_finish_output+0x38c/0x638
ip6_output+0x1b4/0x338
ip6_local_out+0x7c/0xa8
ip6_send_skb+0x7c/0x1b0
ip6_push_pending_frames+0x94/0xd0
rawv6_sendmsg+0x1a98/0x2898
inet_sendmsg+0x94/0xe0
__sys_sendto+0x1e4/0x308
__arm64_sys_sendto+0xc4/0x140
do_el0_svc+0x110/0x280
el0_svc+0x20/0x60
el0t_64_sync_handler+0x104/0x138
el0t_64_sync+0x154/0x158
To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could
be dequeued after ieee80211_do_stop() (new packets cannot be queued
because SDATA_STATE_RUNNING is cleared at this point).
CVE-2025-37794
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: at76c50x: fix use after free access in at76_disconnect
The memory pointed to by priv is freed at the end of at76_delete_device
function (using ieee80211_free_hw). But the code then accesses the udev
field of the freed object to put the USB device. This may also lead to a
memory leak of the usb device. Fix this by using udev from interface.
CVE-2025-37796
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class handling
This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class
handling. The issue occurs due to a time-of-check/time-of-use condition
in hfsc_change_class() when working with certain child qdiscs like netem
or codel.
The vulnerability works as follows:
1. hfsc_change_class() checks if a class has packets (q.qlen != 0)
2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,
codel, netem) might drop packets and empty the queue
3. The code continues assuming the queue is still non-empty, adding
the class to vttree
4. This breaks HFSC scheduler assumptions that only non-empty classes
are in vttree
5. Later, when the class is destroyed, this can lead to a Use-After-Free
The fix adds a second queue length check after qdisc_peek_len() to verify
the queue wasn't emptied.
CVE-2025-37797
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()
After making all ->qlen_notify() callbacks idempotent, now it is safe to
remove the check of qlen!=0 from both fq_codel_dequeue() and
codel_qdisc_dequeue().
CVE-2025-37798
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential NULL pointer dereference in dev_uevent()
If userspace reads "uevent" device attribute at the same time as another
threads unbinds the device from its driver, change to dev->driver from a
valid pointer to NULL may result in crash. Fix this by using READ_ONCE()
when fetching the pointer, and take bus' drivers klist lock to make sure
driver instance will not disappear while we access it.
Use WRITE_ONCE() when setting the driver pointer to ensure there is no
tearing.
CVE-2025-37800
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: check that event count does not exceed event buffer length
The event count is read from register DWC3_GEVNTCOUNT.
There is a check for the count being zero, but not for exceeding the
event buffer length.
Check that event count does not exceed event buffer length,
avoiding an out-of-bounds access when memcpy'ing the event.
Crash log:
Unable to handle kernel paging request at virtual address ffffffc0129be000
pc : __memcpy+0x114/0x180
lr : dwc3_check_event_buf+0xec/0x348
x3 : 0000000000000030 x2 : 000000000000dfc4
x1 : ffffffc0129be000 x0 : ffffff87aad60080
Call trace:
__memcpy+0x114/0x180
dwc3_interrupt+0x24/0x34
CVE-2025-37810
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
Similarly to the previous patch, we need to safe guard hfsc_dequeue()
too. But for this one, we don't have a reliable reproducer.
CVE-2025-37823
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads
Fix niu_try_msix() to not cause a fatal trap on sparc systems.
Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to
work around a bug in the hardware or firmware.
For each vector entry in the msix table, niu chips will cause a fatal
trap if any registers in that entry are read before that entries'
ENTRY_DATA register is written to. Testing indicates writes to other
registers are not sufficient to prevent the fatal trap, however the value
does not appear to matter. This only needs to happen once after power up,
so simply rebooting into a kernel lacking this fix will NOT cause the
trap.
NON-RESUMABLE ERROR: Reporting on cpu 64
NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <msix_prepare_msi_desc+0x90/0xa0>
NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff
NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]
NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]
NON-RESUMABLE ERROR: type [precise nonresumable]
NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >
NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]
NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]
NON-RESUMABLE ERROR: size [0x8]
NON-RESUMABLE ERROR: asi [0x00]
CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63
Workqueue: events work_for_cpu_fn
TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted
TPC: <msix_prepare_msi_desc+0x90/0xa0>
g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100
g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000
o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620
o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128
RPC: <__pci_enable_msix_range+0x3cc/0x460>
l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020
l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734
i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d
i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0
I7: <niu_try_msix.constprop.0+0xc0/0x130 [niu]>
Call Trace:
[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu]
[<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu]
[<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu]
[<00000000005ef3e4>] local_pci_probe+0x28/0x74
[<0000000000469240>] work_for_cpu_fn+0x8/0x1c
[<000000000046b008>] process_scheduled_works+0x144/0x210
[<000000000046b518>] worker_thread+0x13c/0x1c0
[<00000000004710e0>] kthread+0xb8/0xc8
[<00000000004060c8>] ret_from_fork+0x1c/0x2c
[<0000000000000000>] 0x0
Kernel panic - not syncing: Non-resumable error.
CVE-2025-37833
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix reference leak in pci_register_host_bridge()
If device_register() fails, call put_device() to give up the reference to
avoid a memory leak, per the comment at device_register().
Found by code review.
[bhelgaas: squash Dan Carpenter's double free fix from
https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
CVE-2025-37836
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: avoid NULL pointer dereference in dbg call
cifs_server_dbg() implies server to be non-NULL so
move call under condition to avoid NULL pointer dereference.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-37844
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()
Add error handling to propagate amdgpu_cgs_create_device() failures
to the caller. When amdgpu_cgs_create_device() fails, release hwmgr
and return -ENOMEM to prevent null pointer dereference.
[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.
CVE-2025-37852
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: harden block_group::bg_list against list_del() races
As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.
However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.
Otherwise we risk the following interleaving (bg_list refcount in parens)
T1 (some random op) T2 (btrfs_mark_bg_unused)
!list_empty(&bg->bg_list); (1)
list_del_init(&bg->bg_list); (1)
list_move_tail (1)
btrfs_put_block_group (0)
btrfs_delete_unused_bgs
bg = list_first_entry
list_del_init(&bg->bg_list);
btrfs_put_block_group(bg); (-1)
Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING.
CVE-2025-37856
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: pidff: Fix null pointer dereference in pidff_find_fields
This function triggered a null pointer dereference if used to search for
a report that isn't implemented on the device. This happened both for
optional and required reports alike.
The same logic was applied to pidff_find_special_field and although
pidff_init_fields should return an error earlier if one of the required
reports is missing, future modifications could change this logic and
resurface this possible null pointer dereference again.
LKML bug report:
https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com
CVE-2025-37862
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
9p/net: fix improper handling of bogus negative read/write replies
In p9_client_write() and p9_client_read_once(), if the server
incorrectly replies with success but a negative write/read count then we
would consider written (negative) <= rsize (positive) because both
variables were signed.
Make variables unsigned to avoid this problem.
The reproducer linked below now fails with the following error instead
of a null pointer deref:
9pnet: bogus RWRITE count (4294967295 > 3)
CVE-2025-37879
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reset IRTE to host control if *new* route isn't postable
Restore an IRTE back to host control (remapped or posted MSI mode) if the
*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of
the GSI routing type. Updating the IRTE if and only if the new GSI is an
MSI results in KVM leaving an IRTE posting to a vCPU.
The dangling IRTE can result in interrupts being incorrectly delivered to
the guest, and in the worst case scenario can result in use-after-free,
e.g. if the VM is torn down, but the underlying host IRQ isn't freed.
CVE-2025-37885
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mtd: inftlcore: Add error check for inftl_read_oob()
In INFTL_findwriteunit(), the return value of inftl_read_oob()
need to be checked. A proper implementation can be
found in INFTL_deleteblock(). The status will be set as
SECTOR_IGNORE to break from the while-loop correctly
if the inftl_read_oob() fails.
CVE-2025-37892
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix out-of-bound memcpy() during ethtool -w
When retrieving the FW coredump using ethtool, it can sometimes cause
memory corruption:
BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]
Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):
__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]
ethtool_get_dump_data+0xdc/0x1a0
__dev_ethtool+0xa1e/0x1af0
dev_ethtool+0xa8/0x170
dev_ioctl+0x1b5/0x580
sock_do_ioctl+0xab/0xf0
sock_ioctl+0x1ce/0x2e0
__x64_sys_ioctl+0x87/0xc0
do_syscall_64+0x5c/0xf0
entry_SYSCALL_64_after_hwframe+0x78/0x80
...
This happens when copying the coredump segment list in
bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.
The info->dest_buf buffer is allocated based on the number of coredump
segments returned by the FW. The segment list is then DMA'ed by
the FW and the length of the DMA is returned by FW. The driver then
copies this DMA'ed segment list to info->dest_buf.
In some cases, this DMA length may exceed the info->dest_buf length
and cause the above BUG condition. Fix it by capping the copy
length to not exceed the length of info->dest_buf. The extra
DMA data contains no useful information.
This code path is shared for the HWRM_DBG_COREDUMP_LIST and the
HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different
for these 2 FW commands. To simplify the logic, we need to move
the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE
up, so that the new check to cap the copy length will work for both
commands.
CVE-2025-37911
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xsk: Fix race condition in AF_XDP generic RX path
Move rx_lock from xsk_socket to xsk_buff_pool.
Fix synchronization for shared umem mode in
generic RX path where multiple sockets share
single xsk_buff_pool.
RX queue is exclusive to xsk_socket, while FILL
queue can be shared between multiple sockets.
This could result in race condition where two
CPU cores access RX path of two different sockets
sharing the same umem.
Protect both queues by acquiring spinlock in shared
xsk_buff_pool.
Lock contention may be minimized in the future by some
per-thread FQ buffering.
It's safe and necessary to move spin_lock_bh(rx_lock)
after xsk_rcv_check():
* xs->pool and spinlock_init is synchronized by
xsk_bind() -> xsk_is_bound() memory barriers.
* xsk_rcv_check() may return true at the moment
of xsk_release() or xsk_unbind_dev(),
however this will not cause any data races or
race conditions. xsk_unbind_dev() removes xdp
socket from all maps and waits for completion
of all outstanding rx operations. Packets in
RX path will either complete safely or drop.
CVE-2025-37920
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix oob write in trace_seq_to_buffer()
syzbot reported this bug:
==================================================================
BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260
CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xc3/0x670 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
__asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106
trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
....
==================================================================
It has been reported that trace_seq_to_buffer() tries to copy more data
than PAGE_SIZE to buf. Therefore, to prevent this, we should use the
smaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.
CVE-2025-37923
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid
or uid buffers. Comparing ACPIID_LEN against a total string length doesn't
take into account the lengths of individual hid and uid buffers so the
check is insufficient in some cases. For example if the length of hid
string is 4 and the length of the uid string is 260, the length of str
will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer
which size is 256.
The same applies to the hid string with length 13 and uid string with
length 250.
Check the length of hid and uid strings separately to prevent
buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-37927
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dm-bufio: don't schedule in atomic context
A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and
try_verify_in_tasklet are enabled.
[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421
[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4
[ 129.444740][ T934] preempt_count: 201, expected: 0
[ 129.444756][ T934] RCU nest depth: 0, expected: 0
[ 129.444781][ T934] Preemption disabled at:
[ 129.444789][ T934] [<ffffffd816231900>] shrink_work+0x21c/0x248
[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16!
[ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0
[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8
[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)
[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work
[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug]
[ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c
[ 129.447451][ T934] sp : ffffffc0843dbc90
[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b
[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68
[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900
[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030
[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358
[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003
[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400
[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8
[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0
[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000
[ 129.447647][ T934] Call trace:
[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6]
[ 129.447681][ T934] __might_resched+0x190/0x1a8
[ 129.447694][ T934] shrink_work+0x180/0x248
[ 129.447706][ T934] process_one_work+0x260/0x624
[ 129.447718][ T934] worker_thread+0x28c/0x454
[ 129.447729][ T934] kthread+0x118/0x158
[ 129.447742][ T934] ret_from_fork+0x10/0x20
[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)
[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---
dm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet
is enabled, and __scan will be called in atomic context.
CVE-2025-37928
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs
A malicious BPF program may manipulate the branch history to influence
what the hardware speculates will happen next.
On exit from a BPF program, emit the BHB mititgation sequence.
This is only applied for 'classic' cBPF programs that are loaded by
seccomp.
CVE-2025-37948
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
<TASK>
__wake_up_common_lock+0x82/0xd0
process_msg+0x18e/0x2f0
xenbus_thread+0x165/0x1c0
process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems
like it was xs_wake_up() in this case.
It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed
data.
Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.
Change to keeping two krefs on each request. One for the caller, and
one for xenbus_thread. Each will kref_put() when finished, and the last
will free it.
This use of kref matches the description in
Documentation/core-api/kref.rst
CVE-2025-37949
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix uninit-value for saddr in do_output_route4
syzbot reports for uninit-value for the saddr argument [1].
commit 4754957f04f5 ("ipvs: do not use random local source address for
tunnels") already implies that the input value of saddr
should be ignored but the code is still reading it which can prevent
to connect the route. Fix it by changing the argument to ret_saddr.
[1]
BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147
do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147
__ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330
ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136
ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
__ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118
ip_local_out net/ipv4/ip_output.c:127 [inline]
ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501
udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195
udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483
inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x267/0x380 net/socket.c:727
____sys_sendmsg+0x91b/0xda0 net/socket.c:2566
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620
__sys_sendmmsg+0x41d/0x880 net/socket.c:2702
__compat_sys_sendmmsg net/compat.c:360 [inline]
__do_compat_sys_sendmmsg net/compat.c:367 [inline]
__se_compat_sys_sendmmsg net/compat.c:364 [inline]
__ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364
ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346
do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
__do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306
do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369
entry_SYSENTER_compat_after_hwframe+0x84/0x8e
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4167 [inline]
slab_alloc_node mm/slub.c:4210 [inline]
__kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367
kmalloc_noprof include/linux/slab.h:905 [inline]
ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]
__ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323
ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136
ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626
nf_hook include/linux/netfilter.h:269 [inline]
__ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118
ip_local_out net/ipv4/ip_output.c:127 [inline]
ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501
udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195
udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483
inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x267/0x380 net/socket.c:727
____sys_sendmsg+0x91b/0xda0 net/socket.c:2566
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620
__sys_sendmmsg+0x41d/0x880 net/socket.c:2702
__compat_sys_sendmmsg net/compat.c:360 [inline]
__do_compat_sys_sendmmsg net/compat.c:367 [inline]
__se_compat_sys_sendmmsg net/compat.c:364 [inline]
__ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364
ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346
do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
__do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306
do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369
entry_SYSENTER_compat_after_hwframe+0x84/0x8e
CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)
Hardware name: Google Google Compute Engi
---truncated---
CVE-2025-37961
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users
Support for eBPF programs loaded by unprivileged users is typically
disabled. This means only cBPF programs need to be mitigated for BHB.
In addition, only mitigate cBPF programs that were loaded by an
unprivileged user. Privileged users can also load the same program
via eBPF, making the mitigation pointless.
CVE-2025-37963
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
block: fix resource leak in blk_register_queue() error path
When registering a queue fails after blk_mq_sysfs_register() is
successful but the function later encounters an error, we need
to clean up the blk_mq_sysfs resources.
Add the missing blk_mq_sysfs_unregister() call in the error path
to properly clean up these resources and prevent a memory leak.
CVE-2025-37980
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: wl1251: fix memory leak in wl1251_tx_work
The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails
with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.
CVE-2025-37982
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: phy: leds: fix memory leak
A network restart test on a router led to an out-of-memory condition,
which was traced to a memory leak in the PHY LED trigger code.
The root cause is misuse of the devm API. The registration function
(phy_led_triggers_register) is called from phy_attach_direct, not
phy_probe, and the unregister function (phy_led_triggers_unregister)
is called from phy_detach, not phy_remove. This means the register and
unregister functions can be called multiple times for the same PHY
device, but devm-allocated memory is not freed until the driver is
unbound.
This also prevents kmemleak from detecting the leak, as the devm API
internally stores the allocated pointer.
Fix this by replacing devm_kzalloc/devm_kcalloc with standard
kzalloc/kcalloc, and add the corresponding kfree calls in the unregister
path.
CVE-2025-37989
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Flush gso_skb list too during ->change()
Previously, when reducing a qdisc's limit via the ->change() operation, only
the main skb queue was trimmed, potentially leaving packets in the gso_skb
list. This could result in NULL pointer dereference when we only check
sch->limit against sch->q.qlen.
This patch introduces a new helper, qdisc_dequeue_internal(), which ensures
both the gso_skb list and the main queue are properly flushed when trimming
excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)
are updated to use this helper in their ->change() routines.
CVE-2025-37992
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
module: ensure that kobject_put() is safe for module type kobjects
In 'lookup_or_create_module_kobject()', an internal kobject is created
using 'module_ktype'. So call to 'kobject_put()' on error handling
path causes an attempt to use an uninitialized completion pointer in
'module_kobject_release()'. In this scenario, we just want to release
kobject without an extra synchronization required for a regular module
unloading process, so adding an extra check whether 'complete()' is
actually required makes 'kobject_put()' safe.
CVE-2025-37995
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: Fix unsafe attribute parsing in output_userspace()
This patch replaces the manual Netlink attribute iteration in
output_userspace() with nla_for_each_nested(), which ensures that only
well-formed attributes are processed.
CVE-2025-37998
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()
When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the
child qdisc's peek() operation before incrementing sch->q.qlen and
sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may
trigger an immediate dequeue and potential packet drop. In such cases,
qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog
have not yet been updated, leading to inconsistent queue accounting. This
can leave an empty HFSC class in the active list, causing further
consequences like use-after-free.
This patch fixes the bug by moving the increment of sch->q.qlen and
sch->qstats.backlog before the call to the child qdisc's peek() operation.
This ensures that queue length and backlog are always accurate when packet
drops or dequeues are triggered during the peek.
CVE-2025-38000
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking for bcm_op runtime updates
The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via
hrtimer. The content and also the length of the sequence can be changed
resp reduced at runtime where the 'currframe' counter is then set to zero.
Although this appeared to be a safe operation the updates of 'currframe'
can be triggered from user space and hrtimer context in bcm_can_tx().
Anderson Nascimento created a proof of concept that triggered a KASAN
slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
At the rework of bcm_can_tx() the 'count' variable has been moved into
the protected section as this variable can be modified from both contexts
too.
CVE-2025-38004
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfs: handle failure of nfs_get_lock_context in unlock path
When memory is insufficient, the allocation of nfs_lock_context in
nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat
an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)
as valid and proceed to execute rpc_run_task(), this will trigger a NULL
pointer dereference in nfs4_locku_prepare. For example:
BUG: kernel NULL pointer dereference, address: 000000000000000c
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40
Workqueue: rpciod rpc_async_schedule
RIP: 0010:nfs4_locku_prepare+0x35/0xc2
Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3
RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246
RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40
RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38
R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030
R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30
FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0
Call Trace:
<TASK>
__rpc_execute+0xbc/0x480
rpc_async_schedule+0x2f/0x40
process_one_work+0x232/0x5d0
worker_thread+0x1da/0x3d0
? __pfx_worker_thread+0x10/0x10
kthread+0x10d/0x240
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Modules linked in:
CR2: 000000000000000c
---[ end trace 0000000000000000 ]---
Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and
return NULL to terminate subsequent rpc_run_task, preventing NULL pointer
dereference.
CVE-2025-38023
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xcf/0x610 mm/kasan/report.c:489
kasan_report+0xb5/0xe0 mm/kasan/report.c:602
rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195
rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132
__rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232
rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109
create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052
ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095
ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679
vfs_write fs/read_write.c:677 [inline]
vfs_write+0x26a/0xcc0 fs/read_write.c:659
ksys_write+0x1b8/0x200 fs/read_write.c:731
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the function rxe_create_cq, when rxe_cq_from_init fails, the function
rxe_cleanup will be called to handle the allocated resources. In fact,
some memory resources have already been freed in the function
rxe_cq_from_init. Thus, this problem will occur.
The solution is to let rxe_cleanup do all the work.
CVE-2025-38024
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref
btrfs_prelim_ref() calls the old and new reference variables in the
incorrect order. This causes a NULL pointer dereference because oldref
is passed as NULL to trace_btrfs_prelim_ref_insert().
Note, trace_btrfs_prelim_ref_insert() is being called with newref as
oldref (and oldref as NULL) on purpose in order to print out
the values of newref.
To reproduce:
echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable
Perform some writeback operations.
Backtrace:
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130
Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88
RSP: 0018:ffffce44820077a0 EFLAGS: 00010286
RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b
RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010
R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000
R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540
FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
<TASK>
prelim_ref_insert+0x1c1/0x270
find_parent_nodes+0x12a6/0x1ee0
? __entry_text_end+0x101f06/0x101f09
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
btrfs_is_data_extent_shared+0x167/0x640
? fiemap_process_hole+0xd0/0x2c0
extent_fiemap+0xa5c/0xbc0
? __entry_text_end+0x101f05/0x101f09
btrfs_fiemap+0x7e/0xd0
do_vfs_ioctl+0x425/0x9d0
__x64_sys_ioctl+0x75/0xc0
CVE-2025-38034
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: don't restore null sk_state_change
queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if
the TCP connection isn't established when nvmet_tcp_set_queue_sock() is
called then queue->state_change isn't set and sock->sk->sk_state_change
isn't replaced.
As such we don't need to restore sock->sk->sk_state_change if
queue->state_change is NULL.
This avoids NULL pointer dereferences such as this:
[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode
[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page
[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0
[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI
[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)
[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[ 286.467147][ C0] RIP: 0010:0x0
[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246
[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43
[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100
[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c
[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3
[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268
[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000
[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0
[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400
[ 286.475453][ C0] Call Trace:
[ 286.476102][ C0] <IRQ>
[ 286.476719][ C0] tcp_fin+0x2bb/0x440
[ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60
[ 286.478174][ C0] ? __build_skb_around+0x234/0x330
[ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0
[ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10
[ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0
[ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90
[ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30
[ 286.482769][ C0] ? ktime_get+0x66/0x150
[ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0
[ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050
[ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0
[ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0
[ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10
[ 286.486917][ C0] ? lock_release+0x217/0x2c0
[ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0
[ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30
[ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0
[ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0
[ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10
[ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10
[ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack]
[ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0
[ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370
[ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420
[ 286.494268][ C0] ip_local_deliver+0x168/0x430
[ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10
[ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10
[ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20
[ 286.496806][ C0] ? lock_release+0x217/0x2c0
[ 286.497414][ C0] ip_rcv+0x455/0x6e0
[ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10
[
---truncated---
CVE-2025-38035
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: mctrl_gpio: split disable_ms into sync and no_sync APIs
The following splat has been observed on a SAMA5D27 platform using
atmel_serial:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:738
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec
softirqs last enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec
softirqs last disabled at (0): [<00000000>] 0x0
CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74
Hardware name: Atmel SAMA5
Workqueue: hci0 hci_power_on [bluetooth]
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x44/0x70
dump_stack_lvl from __might_resched+0x38c/0x598
__might_resched from disable_irq+0x1c/0x48
disable_irq from mctrl_gpio_disable_ms+0x74/0xc0
mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4
atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8
atmel_set_termios from uart_change_line_settings+0x15c/0x994
uart_change_line_settings from uart_set_termios+0x2b0/0x668
uart_set_termios from tty_set_termios+0x600/0x8ec
tty_set_termios from ttyport_set_flow_control+0x188/0x1e0
ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]
wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]
hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]
hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]
hci_power_on [bluetooth] from process_one_work+0x998/0x1a38
process_one_work from worker_thread+0x6e0/0xfb4
worker_thread from kthread+0x3d4/0x484
kthread from ret_from_fork+0x14/0x28
This warning is emitted when trying to toggle, at the highest level,
some flow control (with serdev_device_set_flow_control) in a device
driver. At the lowest level, the atmel_serial driver is using
serial_mctrl_gpio lib to enable/disable the corresponding IRQs
accordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to
disable_irq (called in mctrl_gpio_disable_ms) being possibly called in
some atomic context (some tty drivers perform modem lines configuration
in regions protected by port lock).
Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one
and a blocking one. Replace mctrl_gpio_disable_ms calls with the
relevant version depending on whether the call is protected by some port
lock.
CVE-2025-38040
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free in cifs_fill_dirent
There is a race condition in the readdir concurrency process, which may
access the rsp buffer after it has been released, triggering the
following KASAN warning.
==================================================================
BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]
Read of size 4 at addr ffff8880099b819c by task a.out/342975
CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_report+0xce/0x640
kasan_report+0xb8/0xf0
cifs_fill_dirent+0xb03/0xb60 [cifs]
cifs_readdir+0x12cb/0x3190 [cifs]
iterate_dir+0x1a1/0x520
__x64_sys_getdents+0x134/0x220
do_syscall_64+0x4b/0x110
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f996f64b9f9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8
RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e
RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88
R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000
</TASK>
Allocated by task 408:
kasan_save_stack+0x20/0x40
kasan_save_track+0x14/0x30
__kasan_slab_alloc+0x6e/0x70
kmem_cache_alloc_noprof+0x117/0x3d0
mempool_alloc_noprof+0xf2/0x2c0
cifs_buf_get+0x36/0x80 [cifs]
allocate_buffers+0x1d2/0x330 [cifs]
cifs_demultiplex_thread+0x22b/0x2690 [cifs]
kthread+0x394/0x720
ret_from_fork+0x34/0x70
ret_from_fork_asm+0x1a/0x30
Freed by task 342979:
kasan_save_stack+0x20/0x40
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x37/0x50
kmem_cache_free+0x2b8/0x500
cifs_buf_release+0x3c/0x70 [cifs]
cifs_readdir+0x1c97/0x3190 [cifs]
iterate_dir+0x1a1/0x520
__x64_sys_getdents64+0x134/0x220
do_syscall_64+0x4b/0x110
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff8880099b8000
which belongs to the cache cifs_request of size 16588
The buggy address is located 412 bytes inside of
freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0x80000000000040(head|node=0|zone=1)
page_type: f5(slab)
raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000
head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001
head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000
head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
POC is available in the link [1].
The problem triggering process is as follows:
Process 1 Process 2
-----------------------------------
---truncated---
CVE-2025-38051
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock
... or we risk stealing final mntput from sync umount - raising mnt_count
after umount(2) has verified that victim is not busy, but before it
has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see
that it's safe to quietly undo mnt_count increment and leaves dropping
the reference to caller, where it'll be a full-blown mntput().
Check under mount_lock is needed; leaving the current one done before
taking that makes no sense - it's nowhere near common enough to bother
with.
CVE-2025-38058
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
net: pktgen: fix access outside of user given buffer in pktgen_thread_write()
Honour the user given buffer size for the strn_len() calls (otherwise
strn_len() will access memory outside of the user given buffer).
CVE-2025-38061
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
virtio: break and reset virtio devices on device_shutdown()
Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
accesses during the hang.
Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected
Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected
...
It was traced down to virtio-console. Kexec works fine if virtio-console
is not in use.
The issue is that virtio-console continues to write to the MMIO even after
underlying virtio-pci device is reset.
Additionally, Eric noticed that IOMMUs are reset before devices, if
devices are not reset on shutdown they continue to poke at guest memory
and get errors from the IOMMU. Some devices get wedged then.
The problem can be solved by breaking all virtio devices on virtio
bus shutdown, then resetting them.
CVE-2025-38064
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: lzo - Fix compression buffer overrun
Unlike the decompression code, the compression code in LZO never
checked for output overruns. It instead assumes that the caller
always provides enough buffer space, disregarding the buffer length
provided by the caller.
Add a safe compression interface that checks for the end of buffer
before each write. Use the safe interface in crypto/lzo.
CVE-2025-38068
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
libnvdimm/labels: Fix divide error in nd_label_data_init()
If a faulty CXL memory device returns a broken zero LSA size in its
memory device information (Identify Memory Device (Opcode 4000h), CXL
spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm
driver:
Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]
Code and flow:
1) CXL Command 4000h returns LSA size = 0
2) config_size is assigned to zero LSA size (CXL pmem driver):
drivers/cxl/pmem.c: .config_size = mds->lsa_size,
3) max_xfer is set to zero (nvdimm driver):
drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);
4) A subsequent DIV_ROUND_UP() causes a division by zero:
drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */
drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,
drivers/nvdimm/label.c- config_size);
Fix this by checking the config size parameter by extending an
existing check.
CVE-2025-38072
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: protect vq->log_used with vq->mutex
The vhost-scsi completion path may access vq->log_base when vq->log_used is
already set to false.
vhost-thread QEMU-thread
vhost_scsi_complete_cmd_work()
-> vhost_add_used()
-> vhost_add_used_n()
if (unlikely(vq->log_used))
QEMU disables vq->log_used
via VHOST_SET_VRING_ADDR.
mutex_lock(&vq->mutex);
vq->log_used = false now!
mutex_unlock(&vq->mutex);
QEMU gfree(vq->log_base)
log_used()
-> log_write(vq->log_base)
Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be
reclaimed via gfree(). As a result, this causes invalid memory writes to
QEMU userspace.
The control queue path has the same issue.
CVE-2025-38074
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix timeout on deleted connection
NOPIN response timer may expire on a deleted connection and crash with
such logs:
Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d
BUG: Kernel NULL pointer dereference on read at 0x00000000
NIP strlcpy+0x8/0xb0
LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]
Call Trace:
iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod]
call_timer_fn+0x58/0x1f0
run_timer_softirq+0x740/0x860
__do_softirq+0x16c/0x420
irq_exit+0x188/0x1c0
timer_interrupt+0x184/0x410
That is because nopin response timer may be re-started on nopin timer
expiration.
Stop nopin timer before stopping the nopin response timer to be sure
that no one of them will be re-started.
CVE-2025-38075
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix race of buffer access at PCM OSS layer
The PCM OSS layer tries to clear the buffer with the silence data at
initialization (or reconfiguration) of a stream with the explicit call
of snd_pcm_format_set_silence() with runtime->dma_area. But this may
lead to a UAF because the accessed runtime->dma_area might be freed
concurrently, as it's performed outside the PCM ops.
For avoiding it, move the code into the PCM core and perform it inside
the buffer access lock, so that it won't be changed during the
operation.
CVE-2025-38078
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_hash - fix double free in hash_accept
If accept(2) is called on socket type algif_hash with
MSG_MORE flag set and crypto_ahash_import fails,
sk2 is freed. However, it is also freed in af_alg_release,
leading to slab-use-after-free error.
CVE-2025-38079
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net_sched: prio: fix a race in prio_tune()
Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer
fires at the wrong time.
The race is as follows:
CPU 0 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
|
| [5]: lock root
| [6]: rehash
| [7]: qdisc_tree_reduce_backlog()
|
[4]: qdisc_put()
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.
CVE-2025-38083
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macb_halt_tx.
There is a situation where after THALT is set high, TGO stays high as
well. Because jiffies are never updated, as we are in a context with
interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do
not have a deadlock anymore.
CVE-2025-38094
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio
as follow:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
Modules linked in:
CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
RIP: 0010:try_grab_folio+0x106/0x130
Call Trace:
<TASK>
follow_huge_pmd+0x240/0x8e0
follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0
follow_pud_mask.constprop.0.isra.0+0x14a/0x170
follow_page_mask+0x1c2/0x1f0
__get_user_pages+0x176/0x950
__gup_longterm_locked+0x15b/0x1060
? gup_fast+0x120/0x1f0
gup_fast_fallback+0x17e/0x230
get_user_pages_fast+0x5f/0x80
vmci_host_unlocked_ioctl+0x21c/0xf80
RIP: 0033:0x54d2cd
---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast
and can be seen in vmci_ctx_unset_notify which will try to put_page. However
get_user_pages_fast is not finished here and lead to following
try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1
vmci_host_do_set_notify
vmci_host_setup_notify
get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);
lockless_pages_from_mm
gup_pgd_range
gup_huge_pmd // update &context->notify_page
vmci_host_do_set_notify
vmci_ctx_unset_notify
notify_page = context->notify_page;
if (notify_page)
put_page(notify_page); // page is freed
__gup_longterm_locked
__get_user_pages
follow_trans_huge_pmd
try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen
after finish get_user_pages_fast.
CVE-2025-38102
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()
Update struct hid_descriptor to better reflect the mandatory and
optional parts of the HID Descriptor as per USB HID 1.11 specification.
Note: the kernel currently does not parse any optional HID class
descriptors, only the mandatory report descriptor.
Update all references to member element desc[0] to rpt_desc.
Add test to verify bLength and bNumDescriptors values are valid.
Replace the for loop with direct access to the mandatory HID class
descriptor member for the report descriptor. This eliminates the
possibility of getting an out-of-bounds fault.
Add a warning message if the HID descriptor contains any unsupported
optional HID class descriptors.
CVE-2025-38103
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Kill timer properly at removal
The USB-audio MIDI code initializes the timer, but in a rare case, the
driver might be freed without the disconnect call. This leaves the
timer in an active state while the assigned object is released via
snd_usbmidi_free(), which ends up with a kernel warning when the debug
configuration is enabled, as spotted by fuzzer.
For avoiding the problem, put timer_shutdown_sync() at
snd_usbmidi_free(), so that the timer can be killed properly.
While we're at it, replace the existing timer_delete_sync() at the
disconnect callback with timer_shutdown_sync(), too.
CVE-2025-38105
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: red: fix a race in __red_change()
Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer
fires at the wrong time.
The race is as follows:
CPU 0 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
|
| [5]: lock root
| [6]: rehash
| [7]: qdisc_tree_reduce_backlog()
|
[4]: qdisc_put()
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.
CVE-2025-38108
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: Fix TOCTOU issue in sk_is_readable()
sk->sk_prot->sock_is_readable is a valid function pointer when sk resides
in a sockmap. After the last sk_psock_put() (which usually happens when
socket is removed from sockmap), sk->sk_prot gets restored and
sk->sk_prot->sock_is_readable becomes NULL.
This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded
after the initial check. Which in turn may lead to a null pointer
dereference.
Ensure the function pointer does not turn NULL after the check.
CVE-2025-38112
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: fix a potential crash on gso_skb handling
SFQ has an assumption of always being able to queue at least one packet.
However, after the blamed commit, sch->q.len can be inflated by packets
in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed
by an immediate drop.
Fix sfq_drop() to properly clear q->tail in this situation.
ip netns add lb
ip link add dev to-lb type veth peer name in-lb netns lb
ethtool -K to-lb tso off # force qdisc to requeue gso_skb
ip netns exec lb ethtool -K in-lb gro on # enable NAPI
ip link set dev to-lb up
ip -netns lb link set dev in-lb up
ip addr add dev to-lb 192.168.20.1/24
ip -netns lb addr add dev in-lb 192.168.20.2/24
tc qdisc replace dev to-lb root sfq limit 100
ip netns exec lb netserver
netperf -H 192.168.20.2 -l 100 &
netperf -H 192.168.20.2 -l 100 &
netperf -H 192.168.20.2 -l 100 &
netperf -H 192.168.20.2 -l 100 &
CVE-2025-38115
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Protect mgmt_pending list with its own lock
This uses a mutex to protect from concurrent access of mgmt_pending
list which can cause crashes like:
==================================================================
BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91
Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318
CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call trace:
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)
__dump_stack+0x30/0x40 lib/dump_stack.c:94
dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120
print_address_description+0xa8/0x254 mm/kasan/report.c:408
print_report+0x68/0x84 mm/kasan/report.c:521
kasan_report+0xb0/0x110 mm/kasan/report.c:634
__asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379
hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91
mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223
pending_find net/bluetooth/mgmt.c:947 [inline]
remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445
hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712
hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg net/socket.c:727 [inline]
sock_write_iter+0x25c/0x378 net/socket.c:1131
new_sync_write fs/read_write.c:591 [inline]
vfs_write+0x62c/0x97c fs/read_write.c:684
ksys_write+0x120/0x210 fs/read_write.c:736
__do_sys_write fs/read_write.c:747 [inline]
__se_sys_write fs/read_write.c:744 [inline]
__arm64_sys_write+0x7c/0x90 fs/read_write.c:744
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Allocated by task 7037:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x40/0x78 mm/kasan/common.c:68
kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4327 [inline]
__kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339
kmalloc_noprof include/linux/slab.h:909 [inline]
sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198
sk_alloc+0x44/0x3ac net/core/sock.c:2254
bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148
hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202
bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132
__sock_create+0x43c/0x91c net/socket.c:1541
sock_create net/socket.c:1599 [inline]
__sys_socket_create net/socket.c:1636 [inline]
__sys_socket+0xd4/0x1c0 net/socket.c:1683
__do_sys_socket net/socket.c:1697 [inline]
__se_sys_socket net/socket.c:1695 [inline]
__arm64_sys_socket+0x7c/0x94 net/socket.c:1695
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Freed by task 6607:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x40/0x78 mm/kasan/common.c:68
kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x68/0x88 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline
---truncated---
CVE-2025-38117
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO
gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()
did not check for this case before dereferencing the returned pointer.
Add a missing NULL check to prevent a potential NULL pointer
dereference when allocation fails.
This improves robustness in low-memory scenarios.
CVE-2025-38122
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping
The stmmac platform drivers that do not open-code the clk_ptp_rate value
after having retrieved the default one from the device-tree can end up
with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will
eventually propagate up to PTP initialization when bringing up the
interface, leading to a divide by 0:
Division by zero in kernel.
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22
Hardware name: STM32 (Device Tree Support)
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x6c/0x8c
dump_stack_lvl from Ldiv0_64+0x8/0x18
Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4
stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c
stmmac_hw_setup from __stmmac_open+0x18c/0x434
__stmmac_open from stmmac_open+0x3c/0xbc
stmmac_open from __dev_open+0xf4/0x1ac
__dev_open from __dev_change_flags+0x1cc/0x224
__dev_change_flags from dev_change_flags+0x24/0x60
dev_change_flags from ip_auto_config+0x2e8/0x11a0
ip_auto_config from do_one_initcall+0x84/0x33c
do_one_initcall from kernel_init_freeable+0x1b8/0x214
kernel_init_freeable from kernel_init+0x24/0x140
kernel_init from ret_from_fork+0x14/0x28
Exception stack(0xe0815fb0 to 0xe0815ff8)
Prevent this division by 0 by adding an explicit check and error log
about the actual issue. While at it, remove the same check from
stmmac_ptp_register, which then becomes duplicate
CVE-2025-38126
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
calipso: Don't call calipso functions for AF_INET sk.
syzkaller reported a null-ptr-deref in txopt_get(). [0]
The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,
so struct ipv6_pinfo was NULL there.
However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6
is always set in inet6_create(), meaning the socket was not IPv6 one.
The root cause is missing validation in netlbl_conn_setattr().
netlbl_conn_setattr() switches branches based on struct
sockaddr.sa_family, which is passed from userspace. However,
netlbl_conn_setattr() does not check if the address family matches
the socket.
The syzkaller must have called connect() for an IPv6 address on
an IPv4 socket.
We have a proper validation in tcp_v[46]_connect(), but
security_socket_connect() is called in the earlier stage.
Let's copy the validation to netlbl_conn_setattr().
[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]
RIP: 0010:
Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00
RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c
RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070
RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e
R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00
R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80
FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
<TASK>
calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557
netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177
selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569
selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline]
selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615
selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931
security_socket_connect+0x50/0xa0 security/security.c:4598
__sys_connect_file+0xa4/0x190 net/socket.c:2067
__sys_connect+0x12c/0x170 net/socket.c:2088
__do_sys_connect net/socket.c:2098 [inline]
__se_sys_connect net/socket.c:2095 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:2095
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f901b61a12d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d
RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003
RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000
</TASK>
Modules linked in:
CVE-2025-38147
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: usb: aqc111: fix error handling of usbnet read calls
Syzkaller, courtesy of syzbot, identified an error (see report [1]) in
aqc111 driver, caused by incomplete sanitation of usb read calls'
results. This problem is quite similar to the one fixed in commit
920a9fa27e78 ("net: asix: add proper error handling of usb read errors").
For instance, usbnet_read_cmd() may read fewer than 'size' bytes,
even if the caller expected the full amount, and aqc111_read_cmd()
will not check its result properly. As [1] shows, this may lead
to MAC address in aqc111_bind() being only partly initialized,
triggering KMSAN warnings.
Fix the issue by verifying that the number of bytes read is
as expected and not less.
[1] Partial syzbot report:
BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline]
BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830
is_valid_ether_addr include/linux/etherdevice.h:208 [inline]
usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830
usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x4d1/0xd90 drivers/base/dd.c:658
__driver_probe_device+0x268/0x380 drivers/base/dd.c:800
...
Uninit was stored to memory at:
dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582
__dev_addr_set include/linux/netdevice.h:4874 [inline]
eth_hw_addr_set include/linux/etherdevice.h:325 [inline]
aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717
usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396
...
Uninit was stored to memory at:
ether_addr_copy include/linux/etherdevice.h:305 [inline]
aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline]
aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713
usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:-1 [inline]
...
Local variable buf.i created at:
aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline]
aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713
usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772
CVE-2025-38153
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k_htc: Abort software beacon handling if disabled
A malicious USB device can send a WMI_SWBA_EVENTID event from an
ath9k_htc-managed device before beaconing has been enabled. This causes
a device-by-zero error in the driver, leading to either a crash or an
out of bounds read.
Prevent this by aborting the handling in ath9k_htc_swba() if beacons are
not enabled.
CVE-2025-38157
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction
Upon RQ destruction if the firmware command fails which is the
last resource to be destroyed some SW resources were already cleaned
regardless of the failure.
Now properly rollback the object to its original state upon such failure.
In order to avoid a use-after free in case someone tries to destroy the
object again, which results in the following kernel trace:
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148
Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)
CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : refcount_warn_saturate+0xf4/0x148
lr : refcount_warn_saturate+0xf4/0x148
sp : ffff80008b81b7e0
x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001
x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00
x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000
x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006
x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f
x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78
x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90
x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff
x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600
Call trace:
refcount_warn_saturate+0xf4/0x148
mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib]
mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib]
mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib]
ib_destroy_wq_user+0x30/0xc0 [ib_core]
uverbs_free_wq+0x28/0x58 [ib_uverbs]
destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs]
uverbs_destroy_uobject+0x48/0x240 [ib_uverbs]
__uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs]
uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs]
ib_uverbs_close+0x2c/0x100 [ib_uverbs]
__fput+0xd8/0x2f0
__fput_sync+0x50/0x70
__arm64_sys_close+0x40/0x90
invoke_syscall.constprop.0+0x74/0xd0
do_el0_svc+0x48/0xe8
el0_svc+0x44/0x1d0
el0t_64_sync_handler+0x120/0x130
el0t_64_sync+0x1a4/0x1a8
CVE-2025-38161
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix ktls panic with sockmap
[ 2172.936997] ------------[ cut here ]------------
[ 2172.936999] kernel BUG at lib/iov_iter.c:629!
......
[ 2172.944996] PKRU: 55555554
[ 2172.945155] Call Trace:
[ 2172.945299] <TASK>
[ 2172.945428] ? die+0x36/0x90
[ 2172.945601] ? do_trap+0xdd/0x100
[ 2172.945795] ? iov_iter_revert+0x178/0x180
[ 2172.946031] ? iov_iter_revert+0x178/0x180
[ 2172.946267] ? do_error_trap+0x7d/0x110
[ 2172.946499] ? iov_iter_revert+0x178/0x180
[ 2172.946736] ? exc_invalid_op+0x50/0x70
[ 2172.946961] ? iov_iter_revert+0x178/0x180
[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20
[ 2172.947446] ? iov_iter_revert+0x178/0x180
[ 2172.947683] ? iov_iter_revert+0x5c/0x180
[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840
[ 2172.948206] tls_sw_sendmsg+0x52/0x80
[ 2172.948420] ? inet_sendmsg+0x1f/0x70
[ 2172.948634] __sys_sendto+0x1cd/0x200
[ 2172.948848] ? find_held_lock+0x2b/0x80
[ 2172.949072] ? syscall_trace_enter+0x140/0x270
[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170
[ 2172.949595] ? find_held_lock+0x2b/0x80
[ 2172.949817] ? syscall_trace_enter+0x140/0x270
[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190
[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0
[ 2172.951036] __x64_sys_sendto+0x24/0x30
[ 2172.951382] do_syscall_64+0x90/0x170
......
After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,
e.g., when the BPF program executes bpf_msg_push_data().
If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,
it will return -ENOSPC and attempt to roll back to the non-zero copy
logic. However, during rollback, msg->msg_iter is reset, but since
msg_pl->sg.size has been increased, subsequent executions will exceed the
actual size of msg_iter.
'''
iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);
'''
The changes in this commit are based on the following considerations:
1. When cork_bytes is set, rolling back to non-zero copy logic is
pointless and can directly go to zero-copy logic.
2. We can not calculate the correct number of bytes to revert msg_iter.
Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes
by the BPF program, it becomes 11-byte data: "abc?de?fgh?".
Then, we set cork_bytes to 6, which means the first 6 bytes have been
processed, and the remaining 5 bytes "?fgh?" will be cached until the
length meets the cork_bytes requirement.
However, some data in "?fgh?" is not within 'sg->msg_iter'
(but in msg_pl instead), especially the data "?" we pushed.
So it doesn't seem as simple as just reverting through an offset of
msg_iter.
3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,
the user-space send() doesn't return an error, and the returned length is
the same as the input length parameter, even if some data is cached.
Additionally, I saw that the current non-zero-copy logic for handling
corking is written as:
'''
line 1177
else if (ret != -EAGAIN) {
if (ret == -ENOSPC)
ret = 0;
goto send_end;
'''
So it's ok to just return 'copied' without error when a "cork" situation
occurs.
CVE-2025-38166
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: marvell/cesa - Handle zero-length skcipher requests
Do not access random memory for zero-length skcipher requests.
Just return 0.
CVE-2025-38173
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Do not double dequeue a configuration request
Some of our devices crash in tb_cfg_request_dequeue():
general protection fault, probably for non-canonical address 0xdead000000000122
CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65
RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0
Call Trace:
<TASK>
? tb_cfg_request_dequeue+0x2d/0xa0
tb_cfg_request_work+0x33/0x80
worker_thread+0x386/0x8f0
kthread+0xed/0x110
ret_from_fork+0x38/0x50
ret_from_fork_asm+0x1b/0x30
The circumstances are unclear, however, the theory is that
tb_cfg_request_work() can be scheduled twice for a request:
first time via frame.callback from ring_work() and second
time from tb_cfg_request(). Both times kworkers will execute
tb_cfg_request_dequeue(), which results in double list_del()
from the ctl->request_queue (the list poison deference hints
at it: 0xdead000000000122).
Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE
bit set.
CVE-2025-38174
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: atm: fix /proc/net/atm/lec handling
/proc/net/atm/lec must ensure safety against dev_lec[] changes.
It appears it had dev_put() calls without prior dev_hold(),
leading to imbalance and UAF.
CVE-2025-38180
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().
syzkaller reported a null-ptr-deref in sock_omalloc() while allocating
a CALIPSO option. [0]
The NULL is of struct sock, which was fetched by sk_to_full_sk() in
calipso_req_setattr().
Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),
reqsk->rsk_listener could be NULL when SYN Cookie is returned to its
client, as hinted by the leading SYN Cookie log.
Here are 3 options to fix the bug:
1) Return 0 in calipso_req_setattr()
2) Return an error in calipso_req_setattr()
3) Alaways set rsk_listener
1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie
for CALIPSO. 3) is also no go as there have been many efforts to reduce
atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35
("tcp/dccp: do not touch listener sk_refcnt under synflood").
As of the blamed commit, SYN Cookie already did not need refcounting,
and no one has stumbled on the bug for 9 years, so no CALIPSO user will
care about SYN Cookie.
Let's return an error in calipso_req_setattr() and calipso_req_delattr()
in the SYN Cookie case.
This can be reproduced by [1] on Fedora and now connect() of nc times out.
[0]:
TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]
RIP: 0010:sock_net include/net/sock.h:655 [inline]
RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806
Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b
RSP: 0018:ffff88811af89038 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400
RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030
RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e
R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000
R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050
FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
<IRQ>
ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288
calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204
calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597
netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249
selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342
selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551
security_inet_conn_request+0x50/0xa0 security/security.c:4945
tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825
tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275
tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328
tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781
tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667
tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904
ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436
ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491
dst_input include/net/dst.h:469 [inline]
ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]
ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netf
---truncated---
CVE-2025-38181
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer
The reproduction steps:
1. create a tun interface
2. enable l2 bearer
3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode
tipc: Node identity 8af312d38a21, cluster identity 4711
tipc: Enabled bearer <eth:syz_tun>, priority 1
Oops: general protection fault
KASAN: null-ptr-deref in range
CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT
Hardware name: QEMU Ubuntu 24.04 PC
RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0
the ub was in fact a struct dev.
when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or
other media when other thread changes it.
fix this by checking media_id.
CVE-2025-38184
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: atmtcp: Free invalid length skb in atmtcp_c_send().
syzbot reported the splat below. [0]
vcc_sendmsg() copies data passed from userspace to skb and passes
it to vcc->dev->ops->send().
atmtcp_c_send() accesses skb->data as struct atmtcp_hdr after
checking if skb->len is 0, but it's not enough.
Also, when skb->len == 0, skb and sk (vcc) were leaked because
dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing
to revert atm_account_tx() in vcc_sendmsg(), which is expected
to be done in atm_pop_raw().
Let's properly free skb with an invalid length in atmtcp_c_send().
[0]:
BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294
atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294
vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x330/0x3d0 net/socket.c:727
____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566
___sys_sendmsg+0x271/0x3b0 net/socket.c:2620
__sys_sendmsg net/socket.c:2652 [inline]
__do_sys_sendmsg net/socket.c:2657 [inline]
__se_sys_sendmsg net/socket.c:2655 [inline]
__x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655
x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4154 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249
kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579
__alloc_skb+0x347/0x7d0 net/core/skbuff.c:670
alloc_skb include/linux/skbuff.h:1336 [inline]
vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x330/0x3d0 net/socket.c:727
____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566
___sys_sendmsg+0x271/0x3b0 net/socket.c:2620
__sys_sendmsg net/socket.c:2652 [inline]
__do_sys_sendmsg net/socket.c:2657 [inline]
__se_sys_sendmsg net/socket.c:2655 [inline]
__x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655
x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
CVE-2025-38185
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: Revert atm_account_tx() if copy_from_iter_full() fails.
In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by
atm_account_tx().
It is expected to be reverted by atm_pop_raw() later called by
vcc->dev->ops->send(vcc, skb).
However, vcc_sendmsg() misses the same revert when copy_from_iter_full()
fails, and then we will leak a socket.
Let's factorise the revert part as atm_return_tx() and call it in
the failure path.
Note that the corresponding sk_wmem_alloc operation can be found in
alloc_tx() as of the blamed commit.
$ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~
CVE-2025-38190
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: clear the dst when changing skb protocol
A not-so-careful NAT46 BPF program can crash the kernel
if it indiscriminately flips ingress packets from v4 to v6:
BUG: kernel NULL pointer dereference, address: 0000000000000000
ip6_rcv_core (net/ipv6/ip6_input.c:190:20)
ipv6_rcv (net/ipv6/ip6_input.c:306:8)
process_backlog (net/core/dev.c:6186:4)
napi_poll (net/core/dev.c:6906:9)
net_rx_action (net/core/dev.c:7028:13)
do_softirq (kernel/softirq.c:462:3)
netif_rx (net/core/dev.c:5326:3)
dev_loopback_xmit (net/core/dev.c:4015:2)
ip_mc_finish_output (net/ipv4/ip_output.c:363:8)
NF_HOOK (./include/linux/netfilter.h:314:9)
ip_mc_output (net/ipv4/ip_output.c:400:5)
dst_output (./include/net/dst.h:459:9)
ip_local_out (net/ipv4/ip_output.c:130:9)
ip_send_skb (net/ipv4/ip_output.c:1496:8)
udp_send_skb (net/ipv4/udp.c:1040:8)
udp_sendmsg (net/ipv4/udp.c:1328:10)
The output interface has a 4->6 program attached at ingress.
We try to loop the multicast skb back to the sending socket.
Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr
and changes skb->protocol to v6. We enter ip6_rcv_core which
tries to use skb_dst(). But the dst is still an IPv4 one left
after IPv4 mcast output.
Clear the dst in all BPF helpers which change the protocol.
Try to preserve metadata dsts, those may carry non-routing
metadata.
CVE-2025-38192
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: reject invalid perturb period
Gerrard Tai reported that SFQ perturb_period has no range check yet,
and this can be used to trigger a race condition fixed in a separate patch.
We want to make sure ctl->perturb_period * HZ will not overflow
and is positive.
tc qd add dev lo root sfq perturb -10 # negative value : error
Error: sch_sfq: invalid perturb period.
tc qd add dev lo root sfq perturb 1000000000 # too big : error
Error: sch_sfq: invalid perturb period.
tc qd add dev lo root sfq perturb 2000000 # acceptable value
tc -s -d qd sh dev lo
qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
CVE-2025-38193
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbcon: Make sure modelist not set on unregistered console
It looks like attempting to write to the "store_modes" sysfs node will
run afoul of unregistered consoles:
UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28
index -1 is out of range for type 'fb_info *[32]'
...
fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122
fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048
fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673
store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113
dev_attr_store+0x55/0x80 drivers/base/core.c:2439
static struct fb_info *fbcon_registered_fb[FB_MAX];
...
static signed char con2fb_map[MAX_NR_CONSOLES];
...
static struct fb_info *fbcon_info_from_console(int console)
...
return fbcon_registered_fb[con2fb_map[console]];
If con2fb_map contains a -1 things go wrong here. Instead, return NULL,
as callers of fbcon_info_from_console() are trying to compare against
existing "info" pointers, so error handling should kick in correctly.
CVE-2025-38198
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix MMIO write access to an invalid page in i40e_clear_hw
When the device sends a specific input, an integer underflow can occur, leading
to MMIO write access to an invalid page.
Prevent the integer underflow by changing the type of related variables.
CVE-2025-38200
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction
The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last
deref") simplified cm_id resource management by freeing cm_id once all
references to the cm_id were removed. The references are removed either
upon completion of iw_cm event handlers or when the application destroys
the cm_id. This commit introduced the use-after-free condition where
cm_id_private object could still be in use by event handler works during
the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a
use-after-free related to destroying CM IDs") addressed this use-after-
free by flushing all pending works at the cm_id destruction.
However, still another use-after-free possibility remained. It happens
with the work objects allocated for each cm_id_priv within
alloc_work_entries() during cm_id creation, and subsequently freed in
dealloc_work_entries() once all references to the cm_id are removed.
If the cm_id's last reference is decremented in the event handler work,
the work object for the work itself gets removed, and causes the use-
after-free BUG below:
BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250
Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091
CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
Workqueue: 0x0 (iw_cm_wq)
Call Trace:
<TASK>
dump_stack_lvl+0x6a/0x90
print_report+0x174/0x554
? __virt_addr_valid+0x208/0x430
? __pwq_activate_work+0x1ff/0x250
kasan_report+0xae/0x170
? __pwq_activate_work+0x1ff/0x250
__pwq_activate_work+0x1ff/0x250
pwq_dec_nr_in_flight+0x8c5/0xfb0
process_one_work+0xc11/0x1460
? __pfx_process_one_work+0x10/0x10
? assign_work+0x16c/0x240
worker_thread+0x5ef/0xfd0
? __pfx_worker_thread+0x10/0x10
kthread+0x3b0/0x770
? __pfx_kthread+0x10/0x10
? rcu_is_watching+0x11/0xb0
? _raw_spin_unlock_irq+0x24/0x50
? rcu_is_watching+0x11/0xb0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x30/0x70
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 147416:
kasan_save_stack+0x2c/0x50
kasan_save_track+0x10/0x30
__kasan_kmalloc+0xa6/0xb0
alloc_work_entries+0xa9/0x260 [iw_cm]
iw_cm_connect+0x23/0x4a0 [iw_cm]
rdma_connect_locked+0xbfd/0x1920 [rdma_cm]
nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]
cma_cm_event_handler+0xae/0x320 [rdma_cm]
cma_work_handler+0x106/0x1b0 [rdma_cm]
process_one_work+0x84f/0x1460
worker_thread+0x5ef/0xfd0
kthread+0x3b0/0x770
ret_from_fork+0x30/0x70
ret_from_fork_asm+0x1a/0x30
Freed by task 147091:
kasan_save_stack+0x2c/0x50
kasan_save_track+0x10/0x30
kasan_save_free_info+0x37/0x60
__kasan_slab_free+0x4b/0x70
kfree+0x13a/0x4b0
dealloc_work_entries+0x125/0x1f0 [iw_cm]
iwcm_deref_id+0x6f/0xa0 [iw_cm]
cm_work_handler+0x136/0x1ba0 [iw_cm]
process_one_work+0x84f/0x1460
worker_thread+0x5ef/0xfd0
kthread+0x3b0/0x770
ret_from_fork+0x30/0x70
ret_from_fork_asm+0x1a/0x30
Last potentially related work creation:
kasan_save_stack+0x2c/0x50
kasan_record_aux_stack+0xa3/0xb0
__queue_work+0x2ff/0x1390
queue_work_on+0x67/0xc0
cm_event_handler+0x46a/0x820 [iw_cm]
siw_cm_upcall+0x330/0x650 [siw]
siw_cm_work_handler+0x6b9/0x2b20 [siw]
process_one_work+0x84f/0x1460
worker_thread+0x5ef/0xfd0
kthread+0x3b0/0x770
ret_from_fork+0x30/0x70
ret_from_fork_asm+0x1a/0x30
This BUG is reproducible by repeating the blktests test case nvme/061
for the rdma transport and the siw driver.
To avoid the use-after-free of cm_id_private work objects, ensure that
the last reference to the cm_id is decremented not in the event handler
works, but in the cm_id destruction context. For that purpose, mo
---truncated---
CVE-2025-38211
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipc: fix to protect IPCS lookups using RCU
syzbot reported that it discovered a use-after-free vulnerability, [0]
[0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/
idr_for_each() is protected by rwsem, but this is not enough. If it is
not protected by RCU read-critical region, when idr_for_each() calls
radix_tree_node_free() through call_rcu() to free the radix_tree_node
structure, the node will be freed immediately, and when reading the next
node in radix_tree_for_each_slot(), the already freed memory may be read.
Therefore, we need to add code to make sure that idr_for_each() is
protected within the RCU read-critical region when we call it in
shm_destroy_orphaned().
CVE-2025-38212
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2025-38213
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var
If fb_add_videomode() in fb_set_var() fails to allocate memory for
fb_videomode, later it may lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info->var.
================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
resize_screen drivers/tty/vt/vt.c:1176 [inline]
vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================
The reason is that fb_info->var is being modified in fb_set_var(), and
then fb_videomode_to_var() is called. If it fails to add the mode to
fb_info->modelist, fb_set_var() returns error, but does not restore the
old value of fb_info->var. Restore fb_info->var on failure the same way
it is done earlier in the function.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-38214
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: inline: fix len overflow in ext4_prepare_inline_data
When running the following code on an ext4 filesystem with inline_data
feature enabled, it will lead to the bug below.
fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666);
ftruncate(fd, 30);
pwrite(fd, "a", 1, (1UL << 40) + 5UL);
That happens because write_begin will succeed as when
ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len
will be truncated, leading to ext4_prepare_inline_data parameter to be 6
instead of 0x10000000006.
Then, later when write_end is called, we hit:
BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);
at ext4_write_inline_data.
Fix it by using a loff_t type for the len parameter in
ext4_prepare_inline_data instead of an unsigned int.
[ 44.545164] ------------[ cut here ]------------
[ 44.545530] kernel BUG at fs/ext4/inline.c:240!
[ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb
[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100
[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49
[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216
[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006
[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738
[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000
[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738
[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000
[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0
[ 44.546523] PKRU: 55555554
[ 44.546523] Call Trace:
[ 44.546523] <TASK>
[ 44.546523] ext4_write_inline_data_end+0x126/0x2d0
[ 44.546523] generic_perform_write+0x17e/0x270
[ 44.546523] ext4_buffered_write_iter+0xc8/0x170
[ 44.546523] vfs_write+0x2be/0x3e0
[ 44.546523] __x64_sys_pwrite64+0x6d/0xc0
[ 44.546523] do_syscall_64+0x6a/0xf0
[ 44.546523] ? __wake_up+0x89/0xb0
[ 44.546523] ? xas_find+0x72/0x1c0
[ 44.546523] ? next_uptodate_folio+0x317/0x330
[ 44.546523] ? set_pte_range+0x1a6/0x270
[ 44.546523] ? filemap_map_pages+0x6ee/0x840
[ 44.546523] ? ext4_setattr+0x2fa/0x750
[ 44.546523] ? do_pte_missing+0x128/0xf70
[ 44.546523] ? security_inode_post_setattr+0x3e/0xd0
[ 44.546523] ? ___pte_offset_map+0x19/0x100
[ 44.546523] ? handle_mm_fault+0x721/0xa10
[ 44.546523] ? do_user_addr_fault+0x197/0x730
[ 44.546523] ? do_syscall_64+0x76/0xf0
[ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60
[ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90
[ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ 44.546523] RIP: 0033:0x7f42999c6687
[ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
[ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012
[ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687
[ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003
[ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000
[ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000
---truncated---
CVE-2025-38222
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().
syzbot reported a warning below during atm_dev_register(). [0]
Before creating a new device and procfs/sysfs for it, atm_dev_register()
looks up a duplicated device by __atm_dev_lookup(). These operations are
done under atm_dev_mutex.
However, when removing a device in atm_dev_deregister(), it releases the
mutex just after removing the device from the list that __atm_dev_lookup()
iterates over.
So, there will be a small race window where the device does not exist on
the device list but procfs/sysfs are still not removed, triggering the
splat.
Let's hold the mutex until procfs/sysfs are removed in
atm_dev_deregister().
[0]:
proc_dir_entry 'atm/atmtcp:0' already registered
WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377
Modules linked in:
CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377
Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48
RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248
RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001
RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140
R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444
FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
proc_create_data+0xbe/0x110 fs/proc/generic.c:585
atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361
atm_dev_register+0x46d/0x890 net/atm/resources.c:113
atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369
atmtcp_attach drivers/atm/atmtcp.c:403 [inline]
atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x115/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f38b3b74459
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459
RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005
RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f
R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac
R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b
</TASK>
CVE-2025-38245
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()
In snd_usb_get_audioformat_uac3(), the length value returned from
snd_usb_ctl_msg() is used directly for memory allocation without
validation. This length is controlled by the USB device.
The allocated buffer is cast to a uac3_cluster_header_descriptor
and its fields are accessed without verifying that the buffer
is large enough. If the device returns a smaller than expected
length, this leads to an out-of-bounds read.
Add a length check to ensure the buffer is large enough for
uac3_cluster_header_descriptor.
CVE-2025-38249
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix use-after-free in vhci_flush()
syzbot reported use-after-free in vhci_flush() without repro. [0]
From the splat, a thread close()d a vhci file descriptor while
its device was being used by iotcl() on another thread.
Once the last fd refcnt is released, vhci_release() calls
hci_unregister_dev(), hci_free_dev(), and kfree() for struct
vhci_data, which is set to hci_dev->dev->driver_data.
The problem is that there is no synchronisation after unlinking
hdev from hci_dev_list in hci_unregister_dev(). There might be
another thread still accessing the hdev which was fetched before
the unlink operation.
We can use SRCU for such synchronisation.
Let's run hci_dev_reset() under SRCU and wait for its completion
in hci_unregister_dev().
Another option would be to restore hci_dev->destruct(), which was
removed in commit 587ae086f6e4 ("Bluetooth: Remove unused
hci-destruct cb"). However, this would not be a good solution, as
we should not run hci_unregister_dev() while there are in-flight
ioctl() requests, which could lead to another data-race KCSAN splat.
Note that other drivers seem to have the same problem, for exmaple,
virtbt_remove().
[0]:
BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718
CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xd2/0x2b0 mm/kasan/report.c:521
kasan_report+0x118/0x150 mm/kasan/report.c:634
skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]
skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937
skb_queue_purge include/linux/skbuff.h:3368 [inline]
vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69
hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]
hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592
sock_do_ioctl+0xd9/0x300 net/socket.c:1190
sock_ioctl+0x576/0x790 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fcf5b98e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929
RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009
RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528
</TASK>
Allocated by task 6535:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
kmalloc_noprof include/linux/slab.h:905 [inline]
kzalloc_noprof include/linux/slab.h:1039 [inline]
vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635
misc_open+0x2bc/0x330 drivers/char/misc.c:161
chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414
do_dentry_open+0xdf0/0x1970 fs/open.c:964
vfs_open+0x3b/0x340 fs/open.c:1094
do_open fs/namei.c:3887 [inline]
path_openat+0x2ee5/0x3830 fs/name
---truncated---
CVE-2025-38250
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bcache: fix NULL pointer in cache_set_flush()
1. LINE#1794 - LINE#1887 is some codes about function of
bch_cache_set_alloc().
2. LINE#2078 - LINE#2142 is some codes about function of
register_cache_set().
3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.
1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
1795 {
...
1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) ||
1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) ||
1862 mempool_init_kmalloc_pool(&c->bio_meta, 2,
1863 sizeof(struct bbio) + sizeof(struct bio_vec) *
1864 bucket_pages(c)) ||
1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) ||
1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio),
1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc",
1870 WQ_MEM_RECLAIM, 0)) ||
1871 bch_journal_alloc(c) ||
1872 bch_btree_cache_alloc(c) ||
1873 bch_open_buckets_alloc(c) ||
1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages)))
1875 goto err;
^^^^^^^^
1876
...
1883 return c;
1884 err:
1885 bch_cache_set_unregister(c);
^^^^^^^^^^^^^^^^^^^^^^^^^^^
1886 return NULL;
1887 }
...
2078 static const char *register_cache_set(struct cache *ca)
2079 {
...
2098 c = bch_cache_set_alloc(&ca->sb);
2099 if (!c)
2100 return err;
^^^^^^^^^^
...
2128 ca->set = c;
2129 ca->set->cache[ca->sb.nr_this_dev] = ca;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
2138 return NULL;
2139 err:
2140 bch_cache_set_unregister(c);
2141 return err;
2142 }
(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and
call bch_cache_set_unregister()(LINE#1885).
(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.
(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the
value to c->cache[], it means that c->cache[] is NULL.
LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().
As (1), in LINE#1885 call
bch_cache_set_unregister()
---> bch_cache_set_stop()
---> closure_queue()
-.-> cache_set_flush() (as below LINE#1624)
1624 static void cache_set_flush(struct closure *cl)
1625 {
...
1654 for_each_cache(ca, c, i)
1655 if (ca->alloc_thread)
^^
1656 kthread_stop(ca->alloc_thread);
...
1665 }
(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the
kernel crash occurred as below:
[ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory
[ 846.713242] bcache: register_bcache() error : failed to register device
[ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered
[ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8
[ 846.714790] PGD 0 P4D 0
[ 846.715129] Oops: 0000 [#1] SMP PTI
[ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1
[ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018
[ 846.716451] Workqueue: events cache_set_flush [bcache]
[ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache]
[ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0
---truncated---
CVE-2025-38263
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: sanitize request list handling
Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of
any list, otherwise a malicious R2T PDU might inject a loop in request
list processing.
CVE-2025-38264
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()
In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,
cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's
then passed to fb_cvt_hperiod(), where it's used as a divider -- division
by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to
avoid such overflow...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
CVE-2025-38312
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix double-free on mc_dev
The blamed commit tried to simplify how the deallocations are done but,
in the process, introduced a double-free on the mc_dev variable.
In case the MC device is a DPRC, a new mc_bus is allocated and the
mc_dev variable is just a reference to one of its fields. In this
circumstance, on the error path only the mc_bus should be freed.
This commit introduces back the following checkpatch warning which is a
false-positive.
WARNING: kfree(NULL) is safe and this check is probably not required
+ if (mc_bus)
+ kfree(mc_bus);
CVE-2025-38313
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and
atomctrl_initialize_mc_reg_table_v2_2() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table()
fails to retrieve vram_info, it returns NULL which is later
dereferenced.
CVE-2025-38319
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: atm: add lec_mutex
syzbot found its way in net/atm/lec.c, and found an error path
in lecd_attach() could leave a dangling pointer in dev_lec[].
Add a mutex to protect dev_lecp[] uses from lecd_attach(),
lec_vcc_attach() and lec_mcast_attach().
Following patch will use this mutex for /proc/net/atm/lec.
BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]
BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142
CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xcd/0x680 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
lecd_attach net/atm/lec.c:751 [inline]
lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 6132:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4328 [inline]
__kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015
alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711
lecd_attach net/atm/lec.c:737 [inline]
lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6132:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x51/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2381 [inline]
slab_free mm/slub.c:4643 [inline]
kfree+0x2b4/0x4d0 mm/slub.c:4842
free_netdev+0x6c5/0x910 net/core/dev.c:11892
lecd_attach net/atm/lec.c:744 [inline]
lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
CVE-2025-38323
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()
Since handle->h_transaction may be a NULL pointer, so we should change it
to call is_handle_aborted(handle) first before dereferencing it.
And the following data-race was reported in my fuzzer:
==================================================================
BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata
write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1:
jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556
__ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358
ext4_do_update_inode fs/ext4/inode.c:5220 [inline]
ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869
__ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074
ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103
....
read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0:
jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512
__ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358
ext4_do_update_inode fs/ext4/inode.c:5220 [inline]
ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869
__ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074
ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103
....
value changed: 0x00000000 -> 0x00000001
==================================================================
This issue is caused by missing data-race annotation for jh->b_modified.
Therefore, the missing annotation needs to be added.
CVE-2025-38337
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an
enqueue operation. This may unexpectedly empty the child qdisc and thus
make an in-flight class passive via qlen_notify(). Most qdiscs do not
expect such behaviour at this point in time and may re-activate the
class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC
case by moving the backlog accounting around, though this turned out to
be incomplete since the parent's parent may run into the issue too.
The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale
class pointers is a recurring pattern at this point, this patch takes
a different approach. Instead of trying to fix the accounting, the patch
ensures that qdisc_tree_reduce_backlog always calls qlen_notify when
the child qdisc is empty. This solves the problem because deletion of
qdiscs always involves a call to qdisc_reset() and / or
qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing
the following qdisc_tree_reduce_backlog() to report to the parent. Note
that this may call qlen_notify on passive classes multiple times. This
is not a problem after the recent patch series that made all the
classful qdiscs qlen_notify() handlers idempotent.
CVE-2025-38350
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()
If an exiting non-autoreaping task has already passed exit_notify() and
calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent
or debugger right after unlock_task_sighand().
If a concurrent posix_cpu_timer_del() runs at that moment, it won't be
able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or
lock_task_sighand() will fail.
Add the tsk->exit_state check into run_posix_cpu_timers() to fix this.
This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because
exit_task_work() is called before exit_notify(). But the check still
makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail
anyway in this case.
CVE-2025-38352
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: ensure the received length does not exceed allocated size
In xdp_linearize_page, when reading the following buffers from the ring,
we forget to check the received length with the true allocate size. This
can lead to an out-of-bound read. This commit adds that missing check.
CVE-2025-38375
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Refuse to evaluate a method if arguments are missing
As reported in [1], a platform firmware update that increased the number
of method parameters and forgot to update a least one of its callers,
caused ACPICA to crash due to use-after-free.
Since this a result of a clear AML issue that arguably cannot be fixed
up by the interpreter (it cannot produce missing data out of thin air),
address it by making ACPICA refuse to evaluate a method if the caller
attempts to pass fewer arguments than expected to it.
CVE-2025-38386
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: do not index invalid pin_assignments
A poorly implemented DisplayPort Alt Mode port partner can indicate
that its pin assignment capabilities are greater than the maximum
value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show
will cause a BRK exception due to an out of bounds array access.
Prevent for loop in pin_assignment_show from accessing
invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX
value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop
condition.
CVE-2025-38391
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
vsock/vmci: Clear the vmci transport packet properly when initializing it
In vmci_transport_packet_init memset the vmci_transport_packet before
populating the fields to avoid any uninitialised data being left in the
structure.
CVE-2025-38403
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check return result of sb_min_blocksize
Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.
Syzkaller forks multiple processes which after mounting the Squashfs
filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000).
Now if this ioctl occurs at the same time another process is in the
process of mounting a Squashfs filesystem on /dev/loop0, the failure
occurs. When this happens the following code in squashfs_fill_super()
fails.
----
msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);
msblk->devblksize_log2 = ffz(~msblk->devblksize);
----
sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.
As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2
is set to 64.
This subsequently causes the
UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36
shift exponent 64 is too large for 64-bit type 'u64' (aka
'unsigned long long')
This commit adds a check for a 0 return by sb_min_blocksize().
CVE-2025-38415
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: do not ping device which has failed to load firmware
Syzkaller reports [1, 2] crashes caused by an attempts to ping
the device which has failed to load firmware. Since such a device
doesn't pass 'ieee80211_register_hw()', an internal workqueue
managed by 'ieee80211_queue_work()' is not yet created and an
attempt to queue work on it causes null-ptr-deref.
[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff
[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217
CVE-2025-38420
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix sample vs do_exit()
Baisheng Gao reported an ARM64 crash, which Mark decoded as being a
synchronous external abort -- most likely due to trying to access
MMIO in bad ways.
The crash further shows perf trying to do a user stack sample while in
exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address
space it is trying to access.
It turns out that we stop perf after we tear down the userspace mm; a
receipie for disaster, since perf likes to access userspace for
various reasons.
Flip this order by moving up where we stop perf in do_exit().
Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER
to abort when the current task does not have an mm (exit_mm() makes
sure to set current->mm = NULL; before commencing with the actual
teardown). Such that CPU wide events don't trip on this same problem.
CVE-2025-38424
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request
If the request being processed is not a v4 compound request, then
examining the cstate can have undefined results.
This patch adds a check that the rpc procedure being executed
(rq_procinfo) is the NFSPROC4_COMPOUND procedure.
CVE-2025-38430
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/scheduler: signal scheduled fence when kill job
When an entity from application B is killed, drm_sched_entity_kill()
removes all jobs belonging to that entity through
drm_sched_entity_kill_jobs_work(). If application A's job depends on a
scheduled fence from application B's job, and that fence is not properly
signaled during the killing process, application A's dependency cannot be
cleared.
This leads to application A hanging indefinitely while waiting for a
dependency that will never be resolved. Fix this issue by ensuring that
scheduled fences are properly signaled when an entity is killed, allowing
dependent applications to continue execution.
CVE-2025-38436
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------
[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430
[...]
[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[ 157.043420] Call Trace:
[ 157.045898] <TASK>
[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0
[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710
[ 157.065567] ? dma_buf_vmap+0x224/0x430
[ 157.069446] ? __warn.cold+0x58/0xe4
[ 157.073061] ? dma_buf_vmap+0x224/0x430
[ 157.077111] ? report_bug+0x1dd/0x390
[ 157.080842] ? handle_bug+0x5e/0xa0
[ 157.084389] ? exc_invalid_op+0x14/0x50
[ 157.088291] ? asm_exc_invalid_op+0x16/0x20
[ 157.092548] ? dma_buf_vmap+0x224/0x430
[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230
[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10
[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10
[ 157.110697] drm_gem_shmem_vmap+0x74/0x710
[ 157.114866] drm_gem_vmap+0xa9/0x1b0
[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0
[ 157.123086] drm_gem_fb_vmap+0xab/0x300
[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
[ 157.133032] ? lockdep_init_map_type+0x19d/0x880
[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0
[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180
[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40
[...]
[ 157.346424] ---[ end trace 0000000000000000 ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
this from happening. The framebuffer's cleanup later puts the handle
references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object
instance") triggers the segmentation fault easily by using the dma-buf
field more widely. The underlying issue with reference counting has
been present before.
v2:
- acquire the handle instead of the BO (Christian)
- fix comment style (Christian)
- drop the Fixes tag (Christian)
- rename err_ gotos
- add missing Link tag
CVE-2025-38449
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Abort __tc_modify_qdisc if parent class does not exist
Lion's patch [1] revealed an ancient bug in the qdisc API.
Whenever a user creates/modifies a qdisc specifying as a parent another
qdisc, the qdisc API will, during grafting, detect that the user is
not trying to attach to a class and reject. However grafting is
performed after qdisc_create (and thus the qdiscs' init callback) is
executed. In qdiscs that eventually call qdisc_tree_reduce_backlog
during init or change (such as fq, hhf, choke, etc), an issue
arises. For example, executing the following commands:
sudo tc qdisc add dev lo root handle a: htb default 2
sudo tc qdisc add dev lo parent a: handle beef fq
Qdiscs such as fq, hhf, choke, etc unconditionally invoke
qdisc_tree_reduce_backlog() in their control path init() or change() which
then causes a failure to find the child class; however, that does not stop
the unconditional invocation of the assumed child qdisc's qlen_notify with
a null class. All these qdiscs make the assumption that class is non-null.
The solution is ensure that qdisc_leaf() which looks up the parent
class, and is invoked prior to qdisc_create(), should return failure on
not finding the class.
In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the
parentid doesn't correspond to a class, so that we can detect it
earlier on and abort before qdisc_create is called.
[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/
CVE-2025-38457
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: clip: Fix potential null-ptr-deref in to_atmarpd().
atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip
causes unregister hang").
However, it is not enough because to_atmarpd() is called without RTNL,
especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable.
Also, there is no RTNL dependency around atmarpd.
Let's use a private mutex and RCU to protect access to atmarpd in
to_atmarpd().
CVE-2025-38460
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_conn_close().
syzbot reported a null-ptr-deref in tipc_conn_close() during netns
dismantle. [0]
tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls
tipc_conn_close() for each tipc_conn.
The problem is that tipc_conn_close() is called after releasing the
IDR lock.
At the same time, there might be tipc_conn_recv_work() running and it
could call tipc_conn_close() for the same tipc_conn and release its
last ->kref.
Once we release the IDR lock in tipc_topsrv_stop(), there is no
guarantee that the tipc_conn is alive.
Let's hold the ref before releasing the lock and put the ref after
tipc_conn_close() in tipc_topsrv_stop().
[0]:
BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435
CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1fc/0x2ef lib/dump_stack.c:118
print_address_description.cold+0x54/0x219 mm/kasan/report.c:256
kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354
kasan_report mm/kasan/report.c:412 [inline]
__asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433
tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]
tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722
ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153
cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553
process_one_work+0x864/0x1570 kernel/workqueue.c:2153
worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
kthread+0x33f/0x460 kernel/kthread.c:259
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Allocated by task 23:
kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625
kmalloc include/linux/slab.h:515 [inline]
kzalloc include/linux/slab.h:709 [inline]
tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192
tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470
process_one_work+0x864/0x1570 kernel/workqueue.c:2153
worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
kthread+0x33f/0x460 kernel/kthread.c:259
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Freed by task 23:
__cache_free mm/slab.c:3503 [inline]
kfree+0xcc/0x210 mm/slab.c:3822
tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]
kref_put include/linux/kref.h:70 [inline]
conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155
process_one_work+0x864/0x1570 kernel/workqueue.c:2153
worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
kthread+0x33f/0x460 kernel/kthread.c:259
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
The buggy address belongs to the object at ffff888099305a00
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 8 bytes inside of
512-byte region [ffff888099305a00, ffff888099305c00)
The buggy address belongs to the page:
page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0
flags: 0xfff00000000100(slab)
raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940
raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
CVE-2025-38464
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix wraparounds of sk->sk_rmem_alloc.
Netlink has this pattern in some places
if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
atomic_add(skb->truesize, &sk->sk_rmem_alloc);
, which has the same problem fixed by commit 5a465a0da13e ("udp:
Fix multiple wraparounds of sk->sk_rmem_alloc.").
For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition
is always false as the two operands are of int.
Then, a single socket can eat as many skb as possible until OOM
happens, and we can see multiple wraparounds of sk->sk_rmem_alloc.
Let's fix it by using atomic_add_return() and comparing the two
variables as unsigned int.
Before:
[root@fedora ~]# ss -f netlink
Recv-Q Send-Q Local Address:Port Peer Address:Port
-1668710080 0 rtnl:nl_wraparound/293 *
After:
[root@fedora ~]# ss -f netlink
Recv-Q Send-Q Local Address:Port Peer Address:Port
2147483072 0 rtnl:nl_wraparound/290 *
^
`--- INT_MAX - 576
CVE-2025-38465
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree
htb_lookup_leaf has a BUG_ON that can trigger with the following:
tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: htb default 1
tc class add dev lo parent 1: classid 1:1 htb rate 64bit
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2:1 handle 3: blackhole
ping -I lo -c1 -W0.001 127.0.0.1
The root cause is the following:
1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on
the selected leaf qdisc
2. netem_dequeue calls enqueue on the child qdisc
3. blackhole_enqueue drops the packet and returns a value that is not
just NET_XMIT_SUCCESS
4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and
since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate ->
htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase
5. As this is the only class in the selected hprio rbtree,
__rb_change_child in __rb_erase_augmented sets the rb_root pointer to
NULL
6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL,
which causes htb_dequeue_tree to call htb_lookup_leaf with the same
hprio rbtree, and fail the BUG_ON
The function graph for this scenario is shown here:
0) | htb_enqueue() {
0) + 13.635 us | netem_enqueue();
0) 4.719 us | htb_activate_prios();
0) # 2249.199 us | }
0) | htb_dequeue() {
0) 2.355 us | htb_lookup_leaf();
0) | netem_dequeue() {
0) + 11.061 us | blackhole_enqueue();
0) | qdisc_tree_reduce_backlog() {
0) | qdisc_lookup_rcu() {
0) 1.873 us | qdisc_match_from_root();
0) 6.292 us | }
0) 1.894 us | htb_search();
0) | htb_qlen_notify() {
0) 2.655 us | htb_deactivate_prios();
0) 6.933 us | }
0) + 25.227 us | }
0) 1.983 us | blackhole_dequeue();
0) + 86.553 us | }
0) # 2932.761 us | qdisc_warn_nonwc();
0) | htb_lookup_leaf() {
0) | BUG_ON();
------------------------------------------
The full original bug report can be seen here [1].
We can fix this just by returning NULL instead of the BUG_ON,
as htb_dequeue_tree returns NULL when htb_lookup_leaf returns
NULL.
[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/
CVE-2025-38468
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime
Assuming the "rx-vlan-filter" feature is enabled on a net device, the
8021q module will automatically add or remove VLAN 0 when the net device
is put administratively up or down, respectively. There are a couple of
problems with the above scheme.
The first problem is a memory leak that can happen if the "rx-vlan-filter"
feature is disabled while the device is running:
# ip link add bond1 up type bond mode 0
# ethtool -K bond1 rx-vlan-filter off
# ip link del dev bond1
When the device is put administratively down the "rx-vlan-filter"
feature is disabled, so the 8021q module will not remove VLAN 0 and the
memory will be leaked [1].
Another problem that can happen is that the kernel can automatically
delete VLAN 0 when the device is put administratively down despite not
adding it when the device was put administratively up since during that
time the "rx-vlan-filter" feature was disabled. null-ptr-unref or
bug_on[2] will be triggered by unregister_vlan_dev() for refcount
imbalance if toggling filtering during runtime:
$ ip link add bond0 type bond mode 0
$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q
$ ethtool -K bond0 rx-vlan-filter off
$ ifconfig bond0 up
$ ethtool -K bond0 rx-vlan-filter on
$ ifconfig bond0 down
$ ip link del vlan0
Root cause is as below:
step1: add vlan0 for real_dev, such as bond, team.
register_vlan_dev
vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1
step2: disable vlan filter feature and enable real_dev
step3: change filter from 0 to 1
vlan_device_event
vlan_filter_push_vids
ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0
step4: real_dev down
vlan_device_event
vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0
vlan_info_rcu_free //free vlan0
step5: delete vlan0
unregister_vlan_dev
BUG_ON(!vlan_info); //vlan_info is null
Fix both problems by noting in the VLAN info whether VLAN 0 was
automatically added upon NETDEV_UP and based on that decide whether it
should be deleted upon NETDEV_DOWN, regardless of the state of the
"rx-vlan-filter" feature.
[1]
unreferenced object 0xffff8880068e3100 (size 256):
comm "ip", pid 384, jiffies 4296130254
hex dump (first 32 bytes):
00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 81ce31fa):
__kmalloc_cache_noprof+0x2b5/0x340
vlan_vid_add+0x434/0x940
vlan_device_event.cold+0x75/0xa8
notifier_call_chain+0xca/0x150
__dev_notify_flags+0xe3/0x250
rtnl_configure_link+0x193/0x260
rtnl_newlink_create+0x383/0x8e0
__rtnl_newlink+0x22c/0xa40
rtnl_newlink+0x627/0xb00
rtnetlink_rcv_msg+0x6fb/0xb70
netlink_rcv_skb+0x11f/0x350
netlink_unicast+0x426/0x710
netlink_sendmsg+0x75a/0xc20
__sock_sendmsg+0xc1/0x150
____sys_sendmsg+0x5aa/0x7b0
___sys_sendmsg+0xfc/0x180
[2]
kernel BUG at net/8021q/vlan.c:99!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))
RSP: 0018:ffff88810badf310 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8
RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80
R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000
R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e
FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0
Call Trace:
<TASK
---truncated---
CVE-2025-38470
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()
syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]
l2cap_sock_resume_cb() has a similar problem that was fixed by commit
1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").
Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed
under l2cap_sock_resume_cb(), we can avoid the issue simply by checking
if chan->data is NULL.
Let's not access to the killed socket in l2cap_sock_resume_cb().
[0]:
BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]
BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]
BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711
Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52
CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Workqueue: hci0 hci_rx_work
Call trace:
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C)
__dump_stack+0x30/0x40 lib/dump_stack.c:94
dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120
print_report+0x58/0x84 mm/kasan/report.c:524
kasan_report+0xb0/0x110 mm/kasan/report.c:634
check_region_inline mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189
__kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37
instrument_atomic_write include/linux/instrumented.h:82 [inline]
clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]
l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711
l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357
hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline]
hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514
hci_event_func net/bluetooth/hci_event.c:7511 [inline]
hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565
hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070
process_one_work+0x7e8/0x155c kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3321 [inline]
worker_thread+0x958/0xed8 kernel/workqueue.c:3402
kthread+0x5fc/0x75c kernel/kthread.c:464
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
CVE-2025-38473
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: net: sierra: check for no status endpoint
The driver checks for having three endpoints and
having bulk in and out endpoints, but not that
the third endpoint is interrupt input.
Rectify the omission.
CVE-2025-38474
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix race condition on qfq_aggregate
A race condition can occur when 'agg' is modified in qfq_change_agg
(called during qfq_enqueue) while other threads access it
concurrently. For example, qfq_dump_class may trigger a NULL
dereference, and qfq_delete_class may cause a use-after-free.
This patch addresses the issue by:
1. Moved qfq_destroy_class into the critical section.
2. Added sch_tree_lock protection to qfq_dump_class and
qfq_dump_class_stats.
CVE-2025-38477
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in crypt_message when using async crypto
The CVE-2024-50047 fix removed asynchronous crypto handling from
crypt_message(), assuming all crypto operations are synchronous.
However, when hardware crypto accelerators are used, this can cause
use-after-free crashes:
crypt_message()
// Allocate the creq buffer containing the req
creq = smb2_get_aead_req(..., &req);
// Async encryption returns -EINPROGRESS immediately
rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);
// Free creq while async operation is still in progress
kvfree_sensitive(creq, ...);
Hardware crypto modules often implement async AEAD operations for
performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,
the operation completes asynchronously. Without crypto_wait_req(),
the function immediately frees the request buffer, leading to crashes
when the driver later accesses the freed memory.
This results in a use-after-free condition when the hardware crypto
driver later accesses the freed request structure, leading to kernel
crashes with NULL pointer dereferences.
The issue occurs because crypto_alloc_aead() with mask=0 doesn't
guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in
the mask, async implementations can be selected.
Fix by restoring the async crypto handling:
- DECLARE_CRYPTO_WAIT(wait) for completion tracking
- aead_request_set_callback() for async completion notification
- crypto_wait_req() to wait for operation completion
This ensures the request buffer isn't freed until the crypto operation
completes, whether synchronous or asynchronous, while preserving the
CVE-2024-50047 fix.
CVE-2025-38488
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
HID: core: do not bypass hid_hw_raw_request
hid_hw_raw_request() is actually useful to ensure the provided buffer
and length are valid. Directly calling in the low level transport driver
function bypassed those checks and allowed invalid paramto be used.
CVE-2025-38494
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
HID: core: ensure the allocated report buffer can contain the reserved report ID
When the report ID is not used, the low level transport drivers expect
the first byte to be 0. However, currently the allocated buffer not
account for that extra byte, meaning that instead of having 8 guaranteed
bytes for implement to be working, we only have 7.
CVE-2025-38495
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
do_change_type(): refuse to operate on unmounted/not ours mounts
Ensure that propagation settings can only be changed for mounts located
in the caller's mount namespace. This change aligns permission checking
with the rest of mount(2).
CVE-2025-38498
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
What we want is to verify there is that clone won't expose something
hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo"
may be a result of MNT_LOCKED on a child, but it may also come from
lacking admin rights in the userns of the namespace mount belongs to.
clone_private_mnt() checks the former, but not the latter.
There's a number of rather confusing CAP_SYS_ADMIN checks in various
userns during the mount, especially with the new mount API; they serve
different purposes and in case of clone_private_mnt() they usually,
but not always end up covering the missing check mentioned above.
CVE-2025-38499
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
wifi: prevent A-MSDU attacks in mesh networks
This patch is a mitigation to prevent the A-MSDU spoofing vulnerability
for mesh networks. The initial update to the IEEE 802.11 standard, in
response to the FragAttacks, missed this case (CVE-2025-27558). It can
be considered a variant of CVE-2020-24588 but for mesh networks.
This patch tries to detect if a standard MSDU was turned into an A-MSDU
by an adversary. This is done by parsing a received A-MSDU as a standard
MSDU, calculating the length of the Mesh Control header, and seeing if
the 6 bytes after this header equal the start of an rfc1042 header. If
equal, this is a strong indication of an ongoing attack attempt.
This defense was tested with mac80211_hwsim against a mesh network that
uses an empty Mesh Address Extension field, i.e., when four addresses
are used, and when using a 12-byte Mesh Address Extension field, i.e.,
when six addresses are used. Functionality of normal MSDUs and A-MSDUs
was also tested, and confirmed working, when using both an empty and
12-byte Mesh Address Extension field.
It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh
networks keep being detected and prevented.
Note that the vulnerability being patched, and the defense being
implemented, was also discussed in the following paper and in the
following IEEE 802.11 presentation:
https://papers.mathyvanhoef.com/wisec2025.pdf
https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
CVE-2025-38512
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()
There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For
example, the following is possible:
T0 T1
zd_mac_tx_to_dev()
/* len == skb_queue_len(q) */
while (len > ZD_MAC_MAX_ACK_WAITERS) {
filter_ack()
spin_lock_irqsave(&q->lock, flags);
/* position == skb_queue_len(q) */
for (i=1; i<position; i++)
skb = __skb_dequeue(q)
if (mac->type == NL80211_IFTYPE_AP)
skb = __skb_dequeue(q);
spin_unlock_irqrestore(&q->lock, flags);
skb_dequeue() -> NULL
Since there is a small gap between checking skb queue length and skb being
unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.
Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.
In order to avoid potential NULL pointer dereference due to situations like
above, check if skb is not NULL before passing it to zd_mac_tx_status().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-38513
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Increment job count before swapping tail spsc queue
A small race exists between spsc_queue_push and the run-job worker, in
which spsc_queue_push may return not-first while the run-job worker has
already idled due to the job count being zero. If this race occurs, job
scheduling stops, leading to hangs while waiting on the job's DMA
fences.
Seal this race by incrementing the job count before appending to the
SPSC queue.
This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in
an SVM test case.
CVE-2025-38515
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a
use-after-free of the cinode structure when unmounting:
cifs_oplock_break()
_cifsFileInfo_put(cfile)
cifsFileInfo_put_final()
cifs_sb_deactive()
[last ref, start releasing sb]
kill_sb()
kill_anon_super()
generic_shutdown_super()
evict_inodes()
dispose_list()
evict()
destroy_inode()
call_rcu(&inode->i_rcu, i_callback)
spin_lock(&cinode->open_file_lock) <- OK
[later] i_callback()
cifs_free_inode()
kmem_cache_free(cinode)
spin_unlock(&cinode->open_file_lock) <- UAF
cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the
superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this
releases the last reference, triggering the immediate cleanup of all
inodes under RCU. However, cifs_oplock_break() continues to access the
cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the
entire oplock break operation. This ensures that the superblock and
its inodes remain valid until the oplock break completes.
CVE-2025-38527
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add down_write(trace_event_sem) when adding trace event
When a module is loaded, it adds trace events defined by the module. It
may also need to modify the modules trace printk formats to replace enum
names with their values.
If two modules are loaded at the same time, the adding of the event to the
ftrace_events list can corrupt the walking of the list in the code that is
modifying the printk format strings and crash the kernel.
The addition of the event should take the trace_event_sem for write while
it adds the new event.
Also add a lockdep_assert_held() on that semaphore in
__trace_add_event_dirs() as it iterates the list.
CVE-2025-38539
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
atm: clip: Fix memory leak of struct clip_vcc.
ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it to
vcc->user_back.
The code assumes that vcc_destroy_socket() passes NULL skb
to vcc->push() when the socket is close()d, and then clip_push()
frees clip_vcc.
However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() in
atm_init_atmarp(), resulting in memory leak.
Let's serialise two ioctl() by lock_sock() and check vcc->push()
in atm_init_atmarp() to prevent memleak.
CVE-2025-38546
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Restrict conditions for adding duplicating netems to qdisc tree
netem_enqueue's duplication prevention logic breaks when a netem
resides in a qdisc tree with other netems - this can lead to a
soft lockup and OOM loop in netem_dequeue, as seen in [1].
Ensure that a duplicating netem cannot exist in a tree with other
netems.
Previous approaches suggested in discussions in chronological order:
1) Track duplication status or ttl in the sk_buff struct. Considered
too specific a use case to extend such a struct, though this would
be a resilient fix and address other previous and potential future
DOS bugs like the one described in loopy fun [2].
2) Restrict netem_enqueue recursion depth like in act_mirred with a
per cpu variable. However, netem_dequeue can call enqueue on its
child, and the depth restriction could be bypassed if the child is a
netem.
3) Use the same approach as in 2, but add metadata in netem_skb_cb
to handle the netem_dequeue case and track a packet's involvement
in duplication. This is an overly complex approach, and Jamal
notes that the skb cb can be overwritten to circumvent this
safeguard.
4) Prevent the addition of a netem to a qdisc tree if its ancestral
path contains a netem. However, filters and actions can cause a
packet to change paths when re-enqueued to the root from netem
duplication, leading us to the current solution: prevent a
duplicating netem from inhabiting the same tree as other netems.
[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/
[2] https://lwn.net/Articles/719297/
CVE-2025-38553
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a
shift-out-of-bounds exception when it tries to convert a 32-bit
quantity to a 0-bit quantity. Ideally this should never occur, but
there are buggy devices and some might have a report field with size
set to zero; we shouldn't reject the report or the device just because
of that.
Instead, harden the s32ton() routine so that it returns a reasonable
result instead of crashing when it is called with the number of bits
set to 0 -- the same as what snto32() does.
CVE-2025-38556
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Prevent VMA split of buffer mappings
The perf mmap code is careful about mmap()'ing the user page with the
ringbuffer and additionally the auxiliary buffer, when the event supports
it. Once the first mapping is established, subsequent mapping have to use
the same offset and the same size in both cases. The reference counting for
the ringbuffer and the auxiliary buffer depends on this being correct.
Though perf does not prevent that a related mapping is split via mmap(2),
munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,
which take reference counts, but then the subsequent perf_mmap_close()
calls are not longer fulfilling the offset and size checks. This leads to
reference count leaks.
As perf already has the requirement for subsequent mappings to match the
initial mapping, the obvious consequence is that VMA splits, caused by
resizing of a mapping or partial unmapping, have to be prevented.
Implement the vm_operations_struct::may_split() callback and return
unconditionally -EINVAL.
That ensures that the mapping offsets and sizes cannot be changed after the
fact. Remapping to a different fixed address with the same size is still
possible as it takes the references for the new mapping and drops those of
the old mapping.
CVE-2025-38563
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ipv6: reject malicious packets in ipv6_gso_segment()
syzbot was able to craft a packet with very long IPv6 extension headers
leading to an overflow of skb->transport_header.
This 16bit field has a limited range.
Add skb_reset_transport_header_careful() helper and use it
from ipv6_gso_segment()
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
Modules linked in:
CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
Call Trace:
<TASK>
skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110
skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
__skb_gso_segment+0x342/0x510 net/core/gso.c:124
skb_gso_segment include/net/gso.h:83 [inline]
validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950
validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000
sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329
__dev_xmit_skb net/core/dev.c:4102 [inline]
__dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679
CVE-2025-38572
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptp_xmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data
on ppp_sync_txmung") fixed ppp_sync_txmunge()
We need a similar fix in pptp_xmit(), otherwise we might
read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193
pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193
ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]
ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314
pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379
sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
__release_sock+0x1d3/0x330 net/core/sock.c:3213
release_sock+0x6b/0x270 net/core/sock.c:3767
pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x330/0x3d0 net/socket.c:727
____sys_sendmsg+0x893/0xd80 net/socket.c:2566
___sys_sendmsg+0x271/0x3b0 net/socket.c:2620
__sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709
CVE-2025-38574
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
iwlwifi: Add missing check for alloc_ordered_workqueue
Add check for the return value of alloc_ordered_workqueue since it may
return NULL pointer.
CVE-2025-38602
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl818x: Kill URBs before clearing tx status queue
In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing
b_tx_status.queue. This change prevents callbacks from using already freed
skb due to anchor was not killed before freeing such skb.
BUG: kernel NULL pointer dereference, address: 0000000000000080
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211]
Call Trace:
<IRQ>
rtl8187_tx_cb+0x116/0x150 [rtl8187]
__usb_hcd_giveback_urb+0x9d/0x120
usb_giveback_urb_bh+0xbb/0x140
process_one_work+0x19b/0x3c0
bh_worker+0x1a7/0x210
tasklet_action+0x10/0x30
handle_softirqs+0xf0/0x340
__irq_exit_rcu+0xcd/0xf0
common_interrupt+0x85/0xa0
</IRQ>
Tested on RTL8187BvE device.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-38604
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can
run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7
("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a
po->bind_lock critical section had to be temporarily released. And
the fix was similarly to temporarily set po->num to zero to keep
the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the
introduction of git history.
CVE-2025-38617
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
vsock: Do not allow binding to VMADDR_PORT_ANY
It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can
cause a use-after-free when a connection is made to the bound socket.
The socket returned by accept() also has port VMADDR_PORT_ANY but is not
on the list of unbound sockets. Binding it will result in an extra
refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep
the binding until socket destruction).
Modify the check in __vsock_bind_connectible() to also prevent binding
to VMADDR_PORT_ANY.
CVE-2025-38618
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
PCI: pnv_php: Fix surprise plug detection and recovery
The existing PowerNV hotplug code did not handle surprise plug events
correctly, leading to a complete failure of the hotplug system after device
removal and a required reboot to detect new devices.
This comes down to two issues:
1) When a device is surprise removed, often the bridge upstream
port will cause a PE freeze on the PHB. If this freeze is not
cleared, the MSI interrupts from the bridge hotplug notification
logic will not be received by the kernel, stalling all plug events
on all slots associated with the PE.
2) When a device is removed from a slot, regardless of surprise or
programmatic removal, the associated PHB/PE ls left frozen.
If this freeze is not cleared via a fundamental reset, skiboot
is unable to clear the freeze and cannot retrain / rescan the
slot. This also requires a reboot to clear the freeze and redetect
the device in the slot.
Issue the appropriate unfreeze and rescan commands on hotplug events,
and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.
[bhelgaas: tidy comments]
CVE-2025-38623
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
PCI: pnv_php: Clean up allocated IRQs on unplug
When the root of a nested PCIe bridge configuration is unplugged, the
pnv_php driver leaked the allocated IRQ resources for the child bridges'
hotplug event notifications, resulting in a panic.
Fix this by walking all child buses and deallocating all its IRQ resources
before calling pci_hp_remove_devices().
Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so
that it is only destroyed in pnv_php_free_slot(), instead of
pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will
now be called by workers triggered by hot unplug interrupts, so the
workqueue needs to stay allocated.
The abridged kernel panic that occurs without this patch is as follows:
WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c
CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2
Call Trace:
msi_device_data_release+0x34/0x9c (unreliable)
release_nodes+0x64/0x13c
devres_release_all+0xc0/0x140
device_del+0x2d4/0x46c
pci_destroy_dev+0x5c/0x194
pci_hp_remove_devices+0x90/0x128
pci_hp_remove_devices+0x44/0x128
pnv_php_disable_slot+0x54/0xd4
power_write_file+0xf8/0x18c
pci_slot_attr_store+0x40/0x5c
sysfs_kf_write+0x64/0x78
kernfs_fop_write_iter+0x1b0/0x290
vfs_write+0x3bc/0x50c
ksys_write+0x84/0x140
system_call_exception+0x124/0x230
system_call_vectored_common+0x15c/0x2ec
[bhelgaas: tidy comments]
CVE-2025-38624
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinmux: fix race causing mux_owner NULL with active mux_usecount
commit 5a3e85c3c397 ("pinmux: Use sequential access to access
desc->pinmux data") tried to address the issue when two client of the
same gpio calls pinctrl_select_state() for the same functionality, was
resulting in NULL pointer issue while accessing desc->mux_owner.
However, issue was not completely fixed due to the way it was handled
and it can still result in the same NULL pointer.
The issue occurs due to the following interleaving:
cpu0 (process A) cpu1 (process B)
pin_request() { pin_free() {
mutex_lock()
desc->mux_usecount--; //becomes 0
..
mutex_unlock()
mutex_lock(desc->mux)
desc->mux_usecount++; // becomes 1
desc->mux_owner = owner;
mutex_unlock(desc->mux)
mutex_lock(desc->mux)
desc->mux_owner = NULL;
mutex_unlock(desc->mux)
This sequence leads to a state where the pin appears to be in use
(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can
cause NULL pointer on next pin_request on the same pin.
Ensure that updates to mux_usecount and mux_owner are performed
atomically under the same lock. Only clear mux_owner when mux_usecount
reaches zero and no new owner has been assigned.
CVE-2025-38632
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net_sched: skbprio: Remove overly strict queue assertions
In the current implementation, skbprio enqueue/dequeue contains an assertion
that fails under certain conditions when SKBPRIO is used as a child qdisc under
TBF with specific parameters. The failure occurs because TBF sometimes peeks at
packets in the child qdisc without actually dequeuing them when tokens are
unavailable.
This peek operation creates a discrepancy between the parent and child qdisc
queue length counters. When TBF later receives a high-priority packet,
SKBPRIO's queue length may show a different value than what's reflected in its
internal priority queue tracking, triggering the assertion.
The fix removes this overly strict assertions in SKBPRIO, they are not
necessary at all.
CVE-2025-38637
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_nfacct: don't assume acct name is null-terminated
BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721
Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851
[..]
string+0x231/0x2b0 lib/vsprintf.c:721
vsnprintf+0x739/0xf00 lib/vsprintf.c:2874
[..]
nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41
xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523
nfnl_acct_find_get() handles non-null input, but the error
printk relied on its presence.
CVE-2025-38639
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: reject TDLS operations when station is not associated
syzbot triggered a WARN in ieee80211_tdls_oper() by sending
NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,
before association completed and without prior TDLS setup.
This left internal state like sdata->u.mgd.tdls_peer uninitialized,
leading to a WARN_ON() in code paths that assumed it was valid.
Reject the operation early if not in station mode or not associated.
CVE-2025-38644
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode
Andrei Lalaev reported a NULL pointer deref when a CAN device is
restarted from Bus Off and the driver does not implement the struct
can_priv::do_set_mode callback.
There are 2 code path that call struct can_priv::do_set_mode:
- directly by a manual restart from the user space, via
can_changelink()
- delayed automatic restart after bus off (deactivated by default)
To prevent the NULL pointer deference, refuse a manual restart or
configure the automatic restart delay in can_changelink() and report
the error via extack to user space.
As an additional safety measure let can_restart() return an error if
can_priv::do_set_mode is not set instead of dereferencing it
unchecked.
CVE-2025-38665
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()
The buffer length check before calling uvc_parse_format() only ensured
that the buffer has at least 3 bytes (buflen > 2), buf the function
accesses buffer[3], requiring at least 4 bytes.
This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.
Fix it by checking that the buffer has at least 4 bytes in
uvc_parse_format().
CVE-2025-38680
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
This issue triggers when a userspace program does an ioctl
FBIOPUT_CON2FBMAP by passing console number and frame buffer number.
Ideally this maps console to frame buffer and updates the screen if
console is visible.
As part of mapping it has to do resize of console according to frame
buffer info. if this resize fails and returns from vc_do_resize() and
continues further. At this point console and new frame buffer are mapped
and sets display vars. Despite failure still it continue to proceed
updating the screen at later stages where vc_data is related to previous
frame buffer and frame buffer info and display vars are mapped to new
frame buffer and eventully leading to out-of-bounds write in
fast_imageblit(). This bheviour is excepted only when fg_console is
equal to requested console which is a visible console and updates screen
with invalid struct references in fbcon_putcs().
CVE-2025-38685
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
pNFS: Fix uninited ptr deref in block/scsi layout
The error occurs on the third attempt to encode extents. When function
ext_tree_prepare_commit() reallocates a larger buffer to retry encoding
extents, the "layoutupdate_pages" page array is initialized only after the
retry loop. But ext_tree_free_commitdata() is called on every iteration
and tries to put pages in the array, thus dereferencing uninitialized
pointers.
An additional problem is that there is no limit on the maximum possible
buffer_size. When there are too many extents, the client may create a
layoutcommit that is larger than the maximum possible RPC size accepted
by the server.
During testing, we observed two typical scenarios. First, one memory page
for extents is enough when we work with small files, append data to the
end of the file, or preallocate extents before writing. But when we fill
a new large file without preallocating, the number of extents can be huge,
and counting the number of written extents in ext_tree_encode_commit()
does not help much. Since this number increases even more between
unlocking and locking of ext_tree, the reallocated buffer may not be
large enough again and again.
CVE-2025-38691
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure
If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the
resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may
occur before sli4_hba.hdwqs are allocated. This may result in a null
pointer dereference when attempting to take the abts_io_buf_list_lock for
the first hardware queue. Fix by adding a null ptr check on
phba->sli4_hba.hdwq and early return because this situation means there
must have been an error during port initialization.
CVE-2025-38695
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: bfa: Double-free fix
When the bfad_im_probe() function fails during initialization, the memory
pointed to by bfad->im is freed without setting bfad->im to NULL.
Subsequently, during driver uninstallation, when the state machine enters
the bfad_sm_stopping state and calls the bfad_im_probe_undo() function,
it attempts to free the memory pointed to by bfad->im again, thereby
triggering a double-free vulnerability.
Set bfad->im to NULL if probing fails.
CVE-2025-38699
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated
In case of an ib_fast_reg_mr allocation failure during iSER setup, the
machine hits a panic because iscsi_conn->dd_data is initialized
unconditionally, even when no memory is allocated (dd_size == 0). This
leads invalid pointer dereference during connection teardown.
Fix by setting iscsi_conn->dd_data only if memory is actually allocated.
Panic trace:
------------
iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12
iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers
BUG: unable to handle page fault for address: fffffffffffffff8
RIP: 0010:swake_up_locked.part.5+0xa/0x40
Call Trace:
complete+0x31/0x40
iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]
iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]
iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]
iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]
? netlink_lookup+0x12f/0x1b0
? netlink_deliver_tap+0x2c/0x200
netlink_unicast+0x1ab/0x280
netlink_sendmsg+0x257/0x4f0
? _copy_from_user+0x29/0x60
sock_sendmsg+0x5f/0x70
CVE-2025-38700
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()
when an inode had the INLINE_DATA_FL flag set but was missing the
system.data extended attribute.
Since this can happen due to a maiciouly fuzzed file system, we
shouldn't BUG, but rather, report it as a corrupted file system.
Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii
ext4_create_inline_data() and ext4_inline_data_truncate().
CVE-2025-38701
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbdev: fix potential buffer overflow in do_register_framebuffer()
The current implementation may lead to buffer overflow when:
1. Unregistration creates NULL gaps in registered_fb[]
2. All array slots become occupied despite num_registered_fb < FB_MAX
3. The registration loop exceeds array bounds
Add boundary check to prevent registered_fb[FB_MAX] access.
CVE-2025-38702
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix null pointer access
Writing a string without delimiters (' ', '\n', '\0') to the under
gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile
will result in a null pointer dereference.
CVE-2025-38705
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
When the volume header contains erroneous values that do not reflect
the actual state of the filesystem, hfsplus_fill_super() assumes that
the attributes file is not yet created, which later results in hitting
BUG_ON() when hfsplus_create_attributes_file() is called. Replace this
BUG_ON() with -EIO error with a message to suggest running fsck tool.
CVE-2025-38712
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
The hfsplus_readdir() method is capable to crash by calling
hfsplus_uni2asc():
[ 667.121659][ T9805] ==================================================================
[ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10
[ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805
[ 667.124578][ T9805]
[ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)
[ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 667.124890][ T9805] Call Trace:
[ 667.124893][ T9805] <TASK>
[ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0
[ 667.124911][ T9805] print_report+0xd0/0x660
[ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610
[ 667.124928][ T9805] ? __phys_addr+0xe8/0x180
[ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10
[ 667.124942][ T9805] kasan_report+0xc6/0x100
[ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10
[ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10
[ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360
[ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0
[ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10
[ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0
[ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20
[ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0
[ 667.125022][ T9805] ? lock_acquire+0x30/0x80
[ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20
[ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0
[ 667.125044][ T9805] ? putname+0x154/0x1a0
[ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10
[ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0
[ 667.125069][ T9805] iterate_dir+0x296/0xb20
[ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0
[ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10
[ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200
[ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10
[ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0
[ 667.125143][ T9805] do_syscall_64+0xc9/0x480
[ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9
[ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48
[ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9
[ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9
[ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004
[ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110
[ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260
[ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 667.125207][ T9805] </TASK>
[ 667.125210][ T9805]
[ 667.145632][ T9805] Allocated by task 9805:
[ 667.145991][ T9805] kasan_save_stack+0x20/0x40
[ 667.146352][ T9805] kasan_save_track+0x14/0x30
[ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0
[ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550
[ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0
[ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0
[ 667.148174][ T9805] iterate_dir+0x296/0xb20
[ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0
[ 667.148937][ T9805] do_syscall_64+0xc9/0x480
[ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 667.149809][ T9805]
[ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000
[ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048
[ 667.151282][ T9805] The buggy address is located 0 bytes to the right of
[ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)
[ 667.1
---truncated---
CVE-2025-38713
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
The hfsplus_bnode_read() method can trigger the issue:
[ 174.852007][ T9784] ==================================================================
[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360
[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784
[ 174.854059][ T9784]
[ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)
[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 174.854286][ T9784] Call Trace:
[ 174.854289][ T9784] <TASK>
[ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0
[ 174.854305][ T9784] print_report+0xd0/0x660
[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610
[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180
[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360
[ 174.854337][ T9784] kasan_report+0xc6/0x100
[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360
[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360
[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380
[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10
[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0
[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310
[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40
[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0
[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0
[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10
[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10
[ 174.854436][ T9784] ? __asan_memset+0x23/0x50
[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320
[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10
[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0
[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40
[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0
[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10
[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0
[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10
[ 174.854525][ T9784] ? down_write+0x148/0x200
[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10
[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0
[ 174.854549][ T9784] do_unlinkat+0x490/0x670
[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10
[ 174.854565][ T9784] ? __might_fault+0xbc/0x130
[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550
[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110
[ 174.854592][ T9784] do_syscall_64+0xc9/0x480
[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167
[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08
[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057
[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167
[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50
[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40
[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0
[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 174.854658][ T9784] </TASK>
[ 174.854661][ T9784]
[ 174.879281][ T9784] Allocated by task 9784:
[ 174.879664][ T9784] kasan_save_stack+0x20/0x40
[ 174.880082][ T9784] kasan_save_track+0x14/0x30
[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0
[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550
[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890
[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10
[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520
[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3
---truncated---
CVE-2025-38714
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sctp: linearize cloned gso packets in sctp_rcv
A cloned head skb still shares these frag skbs in fraglist with the
original head skb. It's not safe to access these frag skbs.
syzbot reported two use-of-uninitialized-memory bugs caused by this:
BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998
sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331
sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122
__release_sock+0x1da/0x330 net/core/sock.c:3106
release_sock+0x6b/0x250 net/core/sock.c:3660
sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360
sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885
sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031
inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:718 [inline]
and
BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88
sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331
sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
__release_sock+0x1d3/0x330 net/core/sock.c:3213
release_sock+0x6b/0x270 net/core/sock.c:3767
sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367
sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886
sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032
inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:712 [inline]
This patch fixes it by linearizing cloned gso packets in sctp_rcv().
CVE-2025-38718
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
Lei Lu recently reported that nfsd4_setclientid_confirm() did not check
the return value from get_client_locked(). a SETCLIENTID_CONFIRM could
race with a confirmed client expiring and fail to get a reference. That
could later lead to a UAF.
Fix this by getting a reference early in the case where there is an
extant confirmed client. If that fails then treat it as if there were no
confirmed client found at all.
In the case where the unconfirmed client is expiring, just fail and
return the result from get_client_locked().
CVE-2025-38724
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable
bLength for avoiding the unexpected OOB accesses by malicious
firmware, too.
CVE-2025-38729
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
gve: prevent ethtool ops after shutdown
A crash can occur if an ethtool operation is invoked
after shutdown() is called.
shutdown() is invoked during system shutdown to stop DMA operations
without performing expensive deallocations. It is discouraged to
unregister the netdev in this path, so the device may still be visible
to userspace and kernel helpers.
In gve, shutdown() tears down most internal data structures. If an
ethtool operation is dispatched after shutdown(), it will dereference
freed or NULL pointers, leading to a kernel panic. While graceful
shutdown normally quiesces userspace before invoking the reboot
syscall, forced shutdowns (as observed on GCP VMs) can still trigger
this path.
Fix by calling netif_device_detach() in shutdown().
This marks the device as detached so the ethtool ioctl handler
will skip dispatching operations to the driver.
CVE-2025-38735
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla4xxx: Prevent a potential error pointer dereference
The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,
but qla4xxx_ep_connect() returns error pointers. Propagating the error
pointers will lead to an Oops in the caller, so change the error pointers
to NULL.
CVE-2025-39676
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix backlog accounting in qdisc_dequeue_internal
This issue applies for the following qdiscs: hhf, fq, fq_codel, and
fq_pie, and occurs in their change handlers when adjusting to the new
limit. The problem is the following in the values passed to the
subsequent qdisc_tree_reduce_backlog call given a tbf parent:
When the tbf parent runs out of tokens, skbs of these qdiscs will
be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,
which accounts for both qlen and backlog. However, in the case of
qdisc_dequeue_internal, ONLY qlen is accounted for when pulling
from gso_skb. This means that these qdiscs are missing a
qdisc_qstats_backlog_dec when dropping packets to satisfy the
new limit in their change handlers.
One can observe this issue with the following (with tc patched to
support a limit of 0):
export TARGET=fq
tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms
tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000
echo ''; echo 'add child'; tc -s -d qdisc show dev lo
ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null
echo ''; echo 'after ping'; tc -s -d qdisc show dev lo
tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0
echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo
tc qdisc replace dev lo handle 2: parent 1:1 sfq
echo ''; echo 'post graft'; tc -s -d qdisc show dev lo
The second to last show command shows 0 packets but a positive
number (74) of backlog bytes. The problem becomes clearer in the
last show command, where qdisc_purge_queue triggers
qdisc_tree_reduce_backlog with the positive backlog and causes an
underflow in the tbf parent's backlog (4096 Mb instead of 0).
To fix this issue, the codepath for all clients of qdisc_dequeue_internal
has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.
qdisc_dequeue_internal handles the backlog adjustments for all cases that
do not directly use the dequeue handler.
The old fq_codel_change limit adjustment loop accumulated the arguments to
the subsequent qdisc_tree_reduce_backlog call through the cstats field.
However, this is confusing and error prone as fq_codel_dequeue could also
potentially mutate this field (which qdisc_dequeue_internal calls in the
non gso_skb case), so we have unified the code here with other qdiscs.
CVE-2025-39677
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs/buffer: fix use-after-free when call bh_read() helper
There's issue as follows:
BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110
Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0
CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
<IRQ>
dump_stack_lvl+0x55/0x70
print_address_description.constprop.0+0x2c/0x390
print_report+0xb4/0x270
kasan_report+0xb8/0xf0
end_buffer_read_sync+0xe3/0x110
end_bio_bh_io_sync+0x56/0x80
blk_update_request+0x30a/0x720
scsi_end_request+0x51/0x2b0
scsi_io_completion+0xe3/0x480
? scsi_device_unbusy+0x11e/0x160
blk_complete_reqs+0x7b/0x90
handle_softirqs+0xef/0x370
irq_exit_rcu+0xa5/0xd0
sysvec_apic_timer_interrupt+0x6e/0x90
</IRQ>
Above issue happens when do ntfs3 filesystem mount, issue may happens
as follows:
mount IRQ
ntfs_fill_super
read_cache_page
do_read_cache_folio
filemap_read_folio
mpage_read_folio
do_mpage_readpage
ntfs_get_block_vbo
bh_read
submit_bh
wait_on_buffer(bh);
blk_complete_reqs
scsi_io_completion
scsi_end_request
blk_update_request
end_bio_bh_io_sync
end_buffer_read_sync
__end_buffer_read_notouch
unlock_buffer
wait_on_buffer(bh);--> return will return to caller
put_bh
--> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is
passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and
wait_on_buffer() returns to continue processing, the stack variable
is likely to be reclaimed. Consequently, during the end_buffer_read_sync()
process, calling put_bh() may result in stack overrun.
If the bh is not allocated on the stack, it belongs to a folio. Freeing
a buffer head which belongs to a folio is done by drop_buffers() which
will fail to free buffers which are still locked. So it is safe to call
put_bh() before __end_buffer_read_notouch().
CVE-2025-39691
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time.
Use the appropriate helper function for this.
CVE-2025-39702
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix a Null pointer dereference vulnerability
[Why]
A null pointer dereference vulnerability exists in the AMD display driver's
(DC module) cleanup function dc_destruct().
When display control context (dc->ctx) construction fails
(due to memory allocation failure), this pointer remains NULL.
During subsequent error handling when dc_destruct() is called,
there's no NULL check before dereferencing the perf_trace member
(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.
[How]
Check if dc->ctx is non-NULL before dereferencing.
(Updated commit text and removed unnecessary error message)
(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)
CVE-2025-39705
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Destroy KFD debugfs after destroy KFD wq
Since KFD proc content was moved to kernel debugfs, we can't destroy KFD
debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior
to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens
when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but
kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line
debugfs_remove_recursive(entry->proc_dentry);
tries to remove /sys/kernel/debug/kfd/proc/<pid> while
/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel
NULL pointer.
(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)
CVE-2025-39706
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: fix panic due to PSLVERR
When the PSLVERR_RESP_EN parameter is set to 1, the device generates
an error response if an attempt is made to read an empty RBR (Receive
Buffer Register) while the FIFO is enabled.
In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,
UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes
dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter
function enables the FIFO via serial_out(p, UART_FCR, p->fcr).
Execution proceeds to the serial_port_in(port, UART_RX).
This satisfies the PSLVERR trigger condition.
When another CPU (e.g., using printk()) is accessing the UART (UART
is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==
(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter
dw8250_force_idle().
Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock
to fix this issue.
Panic backtrace:
[ 0.442336] Oops - unknown exception [#1]
[ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a
[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e
...
[ 0.442416] console_on_rootfs+0x26/0x70
CVE-2025-39724
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: fix concurrency management in ism_cmd()
The s390x ISM device data sheet clearly states that only one
request-response sequence is allowable per ISM function at any point in
time. Unfortunately as of today the s390/ism driver in Linux does not
honor that requirement. This patch aims to rectify that.
This problem was discovered based on Aliaksei's bug report which states
that for certain workloads the ISM functions end up entering error state
(with PEC 2 as seen from the logs) after a while and as a consequence
connections handled by the respective function break, and for future
connection requests the ISM device is not considered -- given it is in a
dysfunctional state. During further debugging PEC 3A was observed as
well.
A kernel message like
[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a
is a reliable indicator of the stated function entering error state
with PEC 2. Let me also point out that a kernel message like
[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery
is a reliable indicator that the ISM function won't be auto-recovered
because the ISM driver currently lacks support for it.
On a technical level, without this synchronization, commands (inputs to
the FW) may be partially or fully overwritten (corrupted) by another CPU
trying to issue commands on the same function. There is hard evidence that
this can lead to DMB token values being used as DMB IOVAs, leading to
PEC 2 PCI events indicating invalid DMA. But this is only one of the
failure modes imaginable. In theory even completely losing one command
and executing another one twice and then trying to interpret the outputs
as if the command we intended to execute was actually executed and not
the other one is also possible. Frankly, I don't feel confident about
providing an exhaustive list of possible consequences.
CVE-2025-39726
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2025-39751
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mm/smaps: fix race between smaps_hugetlb_range and migration
smaps_hugetlb_range() handles the pte without holdling ptl, and may be
concurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page().
The race is as follows.
smaps_hugetlb_range migrate_pages
huge_ptep_get
remove_migration_ptes
folio_unlock
pfn_swap_entry_folio
BUG_ON
To fix it, hold ptl lock in smaps_hugetlb_range().
CVE-2025-39754
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: Prevent file descriptor table allocations exceeding INT_MAX
When sysctl_nr_open is set to a very high value (for example, 1073741816
as set by systemd), processes attempting to use file descriptors near
the limit can trigger massive memory allocation attempts that exceed
INT_MAX, resulting in a WARNING in mm/slub.c:
WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288
This happens because kvmalloc_array() and kvmalloc() check if the
requested size exceeds INT_MAX and emit a warning when the allocation is
not flagged with __GFP_NOWARN.
Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a
process calls dup2(oldfd, 1073741880), the kernel attempts to allocate:
- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes
- Multiple bitmaps: ~400MB
- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)
Reproducer:
1. Set /proc/sys/fs/nr_open to 1073741816:
# echo 1073741816 > /proc/sys/fs/nr_open
2. Run a program that uses a high file descriptor:
#include <unistd.h>
#include <sys/resource.h>
int main() {
struct rlimit rlim = {1073741824, 1073741824};
setrlimit(RLIMIT_NOFILE, &rlim);
dup2(2, 1073741880); // Triggers the warning
return 0;
}
3. Observe WARNING in dmesg at mm/slub.c:5027
systemd commit a8b627a introduced automatic bumping of fs.nr_open to the
maximum possible value. The rationale was that systems with memory
control groups (memcg) no longer need separate file descriptor limits
since memory is properly accounted. However, this change overlooked
that:
1. The kernel's allocation functions still enforce INT_MAX as a maximum
size regardless of memcg accounting
2. Programs and tests that legitimately test file descriptor limits can
inadvertently trigger massive allocations
3. The resulting allocations (>8GB) are impractical and will always fail
systemd's algorithm starts with INT_MAX and keeps halving the value
until the kernel accepts it. On most systems, this results in nr_open
being set to 1073741816 (0x3ffffff8), which is just under 1GB of file
descriptors.
While processes rarely use file descriptors near this limit in normal
operation, certain selftests (like
tools/testing/selftests/core/unshare_test.c) and programs that test file
descriptor limits can trigger this issue.
Fix this by adding a check in alloc_fdtable() to ensure the requested
allocation size does not exceed INT_MAX. This causes the operation to
fail with -EMFILE instead of triggering a kernel warning and avoids the
impractical >8GB memory allocation request.
CVE-2025-39756
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 cluster segment descriptors
UAC3 class segment descriptors need to be verified whether their sizes
match with the declared lengths and whether they fit with the
allocated buffer sizes, too. Otherwise malicious firmware may lead to
the unexpected OOB accesses.
CVE-2025-39757
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length,
enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the
fields in the descriptor.
CVE-2025-39760
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered
If a synchronous error is detected as a result of user-space process
triggering a 2-bit uncorrected error, the CPU will take a synchronous
error exception such as Synchronous External Abort (SEA) on Arm64. The
kernel will queue a memory_failure() work which poisons the related
page, unmaps the page, and then sends a SIGBUS to the process, so that
a system wide panic can be avoided.
However, no memory_failure() work will be queued when abnormal
synchronous errors occur. These errors can include situations like
invalid PA, unexpected severity, no memory failure config support,
invalid GUID section, etc. In such a case, the user-space process will
trigger SEA again. This loop can potentially exceed the platform
firmware threshold or even trigger a kernel hard lockup, leading to a
system reboot.
Fix it by performing a force kill if no memory_failure() work is queued
for synchronous errors.
[ rjw: Changelog edits ]
CVE-2025-39763
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: remove refcounting in expectation dumpers
Same pattern as previous patch: do not keep the expectation object
alive via refcount, only store a cookie value and then use that
as the skip hint for dump resumption.
AFAICS this has the same issue as the one resolved in the conntrack
dumper, when we do
if (!refcount_inc_not_zero(&exp->use))
to increment the refcount, there is a chance that exp == last, which
causes a double-increment of the refcount and subsequent memory leak.
CVE-2025-39764
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
drm/hisilicon/hibmc: fix the hibmc loaded failed bug
When hibmc loaded failed, the driver use hibmc_unload to free the
resource, but the mutexes in mode.config are not init, which will
access an NULL pointer. Just change goto statement to return, because
hibnc_hw_init() doesn't need to free anything.
CVE-2025-39772
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: fix soft lockup in br_multicast_query_expired()
When set multicast_query_interval to a large value, the local variable
'time' in br_multicast_send_query() may overflow. If the time is smaller
than jiffies, the timer will expire immediately, and then call mod_timer()
again, which creates a loop and may trigger the following soft lockup
issue.
watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]
CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)
Call Trace:
<IRQ>
__netdev_alloc_skb+0x2e/0x3a0
br_ip6_multicast_alloc_query+0x212/0x1b70
__br_multicast_send_query+0x376/0xac0
br_multicast_send_query+0x299/0x510
br_multicast_query_expired.constprop.0+0x16d/0x1b0
call_timer_fn+0x3b/0x2a0
__run_timers+0x619/0x950
run_timer_softirq+0x11c/0x220
handle_softirqs+0x18e/0x560
__irq_exit_rcu+0x158/0x1a0
sysvec_apic_timer_interrupt+0x76/0x90
</IRQ>
This issue can be reproduced with:
ip link add br0 type bridge
echo 1 > /sys/class/net/br0/bridge/multicast_querier
echo 0xffffffffffffffff >
/sys/class/net/br0/bridge/multicast_query_interval
ip link set dev br0 up
The multicast_startup_query_interval can also cause this issue. Similar to
the commit 99b40610956a ("net: bridge: mcast: add and enforce query
interval minimum"), add check for the query interval maximum to fix this
issue.
CVE-2025-39773
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
jbd2: prevent softlockup in jbd2_log_do_checkpoint()
Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()
periodically release j_list_lock after processing a batch of buffers to
avoid long hold times on the j_list_lock. However, since both functions
contend for j_list_lock, the combined time spent waiting and processing
can be significant.
jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when
need_resched() is true to avoid softlockups during prolonged operations.
But jbd2_log_do_checkpoint() only exits its loop when need_resched() is
true, relying on potentially sleeping functions like __flush_batch() or
wait_on_buffer() to trigger rescheduling. If those functions do not sleep,
the kernel may hit a softlockup.
watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]
CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017
Workqueue: writeback wb_workfn (flush-7:2)
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : native_queued_spin_lock_slowpath+0x358/0x418
lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]
Call trace:
native_queued_spin_lock_slowpath+0x358/0x418
jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]
__jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]
add_transaction_credits+0x3bc/0x418 [jbd2]
start_this_handle+0xf8/0x560 [jbd2]
jbd2__journal_start+0x118/0x228 [jbd2]
__ext4_journal_start_sb+0x110/0x188 [ext4]
ext4_do_writepages+0x3dc/0x740 [ext4]
ext4_writepages+0xa4/0x190 [ext4]
do_writepages+0x94/0x228
__writeback_single_inode+0x48/0x318
writeback_sb_inodes+0x204/0x590
__writeback_inodes_wb+0x54/0xf8
wb_writeback+0x2cc/0x3d8
wb_do_writeback+0x2e0/0x2f8
wb_workfn+0x80/0x2a8
process_one_work+0x178/0x3e8
worker_thread+0x234/0x3b8
kthread+0xf0/0x108
ret_from_fork+0x10/0x20
So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid
softlockup.
CVE-2025-39782
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: mdt_loader: Ensure we don't read past the ELF header
When the MDT loader is used in remoteproc, the ELF header is sanitized
beforehand, but that's not necessary the case for other clients.
Validate the size of the firmware buffer to ensure that we don't read
past the end as we iterate over the header. e_phentsize and e_shentsize
are validated as well, to ensure that the assumptions about step size in
the traversal are valid.
CVE-2025-39787
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()
If we find an unexpected generation for the extent buffer we are cloning
at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the
transaction, meaning we allow to persist metadata with an unexpected
generation. Instead of warning only, abort the transaction and return
-EUCLEAN.
CVE-2025-39800
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()
in ntrig_report_version(), hdev parameter passed from hid_probe().
sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null
if hdev->dev.parent->parent is null, usb_dev has
invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned
when usb_rcvctrlpipe() use usb_dev,it trigger
page fault error for address(0xffffffffffffff58)
add null check logic to ntrig_report_version()
before calling hid_to_usb_dev()
CVE-2025-39808
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
sctp: initialize more fields in sctp_v6_from_sk()
syzbot found that sin6_scope_id was not properly initialized,
leading to undefined behavior.
Clear sin6_scope_id and sin6_flowinfo.
BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
__sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983
sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390
sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452
sctp_get_port net/sctp/socket.c:8523 [inline]
sctp_listen_start net/sctp/socket.c:8567 [inline]
sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636
__sys_listen_socket net/socket.c:1912 [inline]
__sys_listen net/socket.c:1927 [inline]
__do_sys_listen net/socket.c:1932 [inline]
__se_sys_listen net/socket.c:1930 [inline]
__x64_sys_listen+0x343/0x4c0 net/socket.c:1930
x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable addr.i.i created at:
sctp_get_port net/sctp/socket.c:8515 [inline]
sctp_listen_start net/sctp/socket.c:8567 [inline]
sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636
__sys_listen_socket net/socket.c:1912 [inline]
__sys_listen net/socket.c:1927 [inline]
__do_sys_listen net/socket.c:1932 [inline]
__se_sys_listen net/socket.c:1930 [inline]
__x64_sys_listen+0x343/0x4c0 net/socket.c:1930
CVE-2025-39812
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix potential warning in trace_printk_seq during ftrace_dump
When calling ftrace_dump_one() concurrently with reading trace_pipe,
a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race
condition.
The issue occurs because:
CPU0 (ftrace_dump) CPU1 (reader)
echo z > /proc/sysrq-trigger
!trace_empty(&iter)
trace_iterator_reset(&iter) <- len = size = 0
cat /sys/kernel/tracing/trace_pipe
trace_find_next_entry_inc(&iter)
__find_next_entry
ring_buffer_empty_cpu <- all empty
return NULL
trace_printk_seq(&iter.seq)
WARN_ON_ONCE(s->seq.len >= s->seq.size)
In the context between trace_empty() and trace_find_next_entry_inc()
during ftrace_dump, the ring buffer data was consumed by other readers.
This caused trace_find_next_entry_inc to return NULL, failing to populate
`iter.seq`. At this point, due to the prior trace_iterator_reset, both
`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,
the WARN_ON_ONCE condition is triggered.
Move the trace_printk_seq() into the if block that checks to make sure the
return value of trace_find_next_entry_inc() is non-NULL in
ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before
subsequent operations.
CVE-2025-39813
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in `smb2_compound_op`.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to `cfile` should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
`cfile`, except the patched one.
3. Existing callers would not handle refcount update of `cfile` if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of `vars`, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.
CVE-2025-39819
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
HID: asus: fix UAF via HID_CLAIMED_INPUT validation
After hid_hw_start() is called hidinput_connect() will eventually be
called to set up the device with the input layer since the
HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()
all input and output reports are processed and corresponding hid_inputs
are allocated and configured via hidinput_configure_usages(). This
process involves slot tagging report fields and configuring usages
by setting relevant bits in the capability bitmaps. However it is possible
that the capability bitmaps are not set at all leading to the subsequent
hidinput_has_been_populated() check to fail leading to the freeing of the
hid_input and the underlying input device.
This becomes problematic because a malicious HID device like a
ASUS ROG N-Key keyboard can trigger the above scenario via a
specially crafted descriptor which then leads to a user-after-free
when the name of the freed input device is written to later on after
hid_hw_start(). Below, report 93 intentionally utilises the
HID_UP_UNDEFINED Usage Page which is skipped during usage
configuration, leading to the frees.
0x05, 0x0D, // Usage Page (Digitizer)
0x09, 0x05, // Usage (Touch Pad)
0xA1, 0x01, // Collection (Application)
0x85, 0x0D, // Report ID (13)
0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00)
0x09, 0xC5, // Usage (0xC5)
0x15, 0x00, // Logical Minimum (0)
0x26, 0xFF, 0x00, // Logical Maximum (255)
0x75, 0x08, // Report Size (8)
0x95, 0x04, // Report Count (4)
0xB1, 0x02, // Feature (Data,Var,Abs)
0x85, 0x5D, // Report ID (93)
0x06, 0x00, 0x00, // Usage Page (Undefined)
0x09, 0x01, // Usage (0x01)
0x15, 0x00, // Logical Minimum (0)
0x26, 0xFF, 0x00, // Logical Maximum (255)
0x75, 0x08, // Report Size (8)
0x95, 0x1B, // Report Count (27)
0x81, 0x02, // Input (Data,Var,Abs)
0xC0, // End Collection
Below is the KASAN splat after triggering the UAF:
[ 21.672709] ==================================================================
[ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80
[ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54
[ 21.673700]
[ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)
[ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 21.673700] Call Trace:
[ 21.673700] <TASK>
[ 21.673700] dump_stack_lvl+0x5f/0x80
[ 21.673700] print_report+0xd1/0x660
[ 21.673700] kasan_report+0xe5/0x120
[ 21.673700] __asan_report_store8_noabort+0x1b/0x30
[ 21.673700] asus_probe+0xeeb/0xf80
[ 21.673700] hid_device_probe+0x2ee/0x700
[ 21.673700] really_probe+0x1c6/0x6b0
[ 21.673700] __driver_probe_device+0x24f/0x310
[ 21.673700] driver_probe_device+0x4e/0x220
[...]
[ 21.673700]
[ 21.673700] Allocated by task 54:
[ 21.673700] kasan_save_stack+0x3d/0x60
[ 21.673700] kasan_save_track+0x18/0x40
[ 21.673700] kasan_save_alloc_info+0x3b/0x50
[ 21.673700] __kasan_kmalloc+0x9c/0xa0
[ 21.673700] __kmalloc_cache_noprof+0x139/0x340
[ 21.673700] input_allocate_device+0x44/0x370
[ 21.673700] hidinput_connect+0xcb6/0x2630
[ 21.673700] hid_connect+0xf74/0x1d60
[ 21.673700] hid_hw_start+0x8c/0x110
[ 21.673700] asus_probe+0x5a3/0xf80
[ 21.673700] hid_device_probe+0x2ee/0x700
[ 21.673700] really_probe+0x1c6/0x6b0
[ 21.673700] __driver_probe_device+0x24f/0x310
[ 21.673700] driver_probe_device+0x4e/0x220
[...]
[ 21.673700]
[ 21.673700] Freed by task 54:
[ 21.673700] kasan_save_stack+0x3d/0x60
[ 21.673700] kasan_save_track+0x18/0x40
[ 21.673700] kasan_save_free_info+0x3f/0x60
[ 21.673700] __kasan_slab_free+0x3c/0x50
[ 21.673700] kfre
---truncated---
CVE-2025-39824
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mISDN: hfcpci: Fix warning when deleting uninitialized timer
With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads
to the following splat:
[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0
[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0
[ 250.218775] Modules linked in: hfcpci(-) mISDN_core
[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)
[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0
[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d
[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286
[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95
[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0
[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39
[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001
[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8
[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000
[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0
[ 250.236117] Call Trace:
[ 250.236599] <TASK>
[ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130
[ 250.237920] debug_object_assert_init+0x1f6/0x310
[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10
[ 250.239658] ? __lock_acquire+0xdea/0x1c70
[ 250.240369] __try_to_del_timer_sync+0x69/0x140
[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10
[ 250.242058] ? __timer_delete_sync+0xc6/0x120
[ 250.242842] ? lock_acquire+0x30/0x80
[ 250.243474] ? __timer_delete_sync+0xc6/0x120
[ 250.244262] __timer_delete_sync+0x98/0x120
[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci]
[ 250.245704] __do_sys_delete_module+0x348/0x510
[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10
[ 250.247338] do_syscall_64+0xc1/0x360
[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix this by initializing hfc_tl timer with DEFINE_TIMER macro.
Also, use mod_timer instead of manual timeout update.
CVE-2025-39833
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent NULL pointer dereference in UTF16 conversion
There can be a NULL pointer dereference bug here. NULL is passed to
__cifs_sfu_make_node without checks, which passes it unchecked to
cifs_strndup_to_utf16, which in turn passes it to
cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.
This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and
returns NULL early to prevent dereferencing NULL pointer.
Found by Linux Verification Center (linuxtesting.org) with SVACE
CVE-2025-39838
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix buffer free/clear order in deferred receive path
Fix a use-after-free window by correcting the buffer release sequence in
the deferred receive path. The code freed the RQ buffer first and only
then cleared the context pointer under the lock. Concurrent paths (e.g.,
ABTS and the repost path) also inspect and release the same pointer under
the lock, so the old order could lead to double-free/UAF.
Note that the repost path already uses the correct pattern: detach the
pointer under the lock, then free it after dropping the lock. The
deferred path should do the same.
CVE-2025-39841
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix memory leak in pad_compress_skb
If alloc_skb() fails in pad_compress_skb(), it returns NULL without
releasing the old skb. The caller does:
skb = pad_compress_skb(ppp, skb);
if (!skb)
goto drop;
drop:
kfree_skb(skb);
When pad_compress_skb() returns NULL, the reference to the old skb is
lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.
Align pad_compress_skb() semantics with realloc(): only free the old
skb if allocation and compression succeed. At the call site, use the
new_skb variable so the original skb is not lost when pad_compress_skb()
fails.
CVE-2025-39847
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still
returns a pointer to an invalid object, leading to potential invalid
memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.
CVE-2025-39853
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
syzbot reported the splat below without a repro.
In the splat, a single thread calling bt_accept_dequeue() freed sk
and touched it after that.
The root cause would be the racy l2cap_sock_cleanup_listen() call
added by the cited commit.
bt_accept_dequeue() is called under lock_sock() except for
l2cap_sock_release().
Two threads could see the same socket during the list iteration
in bt_accept_dequeue():
CPU1 CPU2 (close())
---- ----
sock_hold(sk) sock_hold(sk);
lock_sock(sk) <-- block close()
sock_put(sk)
bt_accept_unlink(sk)
sock_put(sk) <-- refcnt by bt_accept_enqueue()
release_sock(sk)
lock_sock(sk)
sock_put(sk)
bt_accept_unlink(sk)
sock_put(sk) <-- last refcnt
bt_accept_unlink(sk) <-- UAF
Depending on the timing, the other thread could show up in the
"Freed by task" part.
Let's call l2cap_sock_cleanup_listen() under lock_sock() in
l2cap_sock_release().
[0]:
BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115
Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995
CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xcd/0x630 mm/kasan/report.c:482
kasan_report+0xe0/0x110 mm/kasan/report.c:595
debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115
spin_lock_bh include/linux/spinlock.h:356 [inline]
release_sock+0x21/0x220 net/core/sock.c:3746
bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312
l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451
l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425
__sock_release+0xb3/0x270 net/socket.c:649
sock_close+0x1c/0x30 net/socket.c:1439
__fput+0x3ff/0xb70 fs/file_table.c:468
task_work_run+0x14d/0x240 kernel/task_work.c:227
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43
exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2accf8ebe9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f
R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c
R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490
</TASK>
Allocated by task 5326:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:388 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4365 [inline]
__kmalloc_nopro
---truncated---
CVE-2025-39860
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
The brcmf_btcoex_detach() only shuts down the btcoex timer, if the
flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which
runs as timer handler, sets timer_on to false. This creates critical
race conditions:
1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()
is executing, it may observe timer_on as false and skip the call to
timer_shutdown_sync().
2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info
worker after the cancel_work_sync() has been executed, resulting in
use-after-free bugs.
The use-after-free bugs occur in two distinct scenarios, depending on
the timing of when the brcmf_btcoex_info struct is freed relative to
the execution of its worker thread.
Scenario 1: Freed before the worker is scheduled
The brcmf_btcoex_info is deallocated before the worker is scheduled.
A race condition can occur when schedule_work(&bt_local->work) is
called after the target memory has been freed. The sequence of events
is detailed below:
CPU0 | CPU1
brcmf_btcoex_detach | brcmf_btcoex_timerfunc
| bt_local->timer_on = false;
if (cfg->btcoex->timer_on) |
... |
cancel_work_sync(); |
... |
kfree(cfg->btcoex); // FREE |
| schedule_work(&bt_local->work); // USE
Scenario 2: Freed after the worker is scheduled
The brcmf_btcoex_info is freed after the worker has been scheduled
but before or during its execution. In this case, statements within
the brcmf_btcoex_handler() - such as the container_of macro and
subsequent dereferences of the brcmf_btcoex_info object will cause
a use-after-free access. The following timeline illustrates this
scenario:
CPU0 | CPU1
brcmf_btcoex_detach | brcmf_btcoex_timerfunc
| bt_local->timer_on = false;
if (cfg->btcoex->timer_on) |
... |
cancel_work_sync(); |
... | schedule_work(); // Reschedule
|
kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker
/* | btci = container_of(....); // USE
The kfree() above could | ...
also occur at any point | btci-> // USE
during the worker's execution|
*/ |
To resolve the race conditions, drop the conditional check and call
timer_shutdown_sync() directly. It can deactivate the timer reliably,
regardless of its current state. Once stopped, the timer_on state is
then set to false.
CVE-2025-39863
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tee: fix NULL pointer dereference in tee_shm_put
tee_shm_put have NULL pointer dereference:
__optee_disable_shm_cache -->
shm = reg_pair_to_ptr(...);//shm maybe return NULL
tee_shm_free(shm); -->
tee_shm_put(shm);//crash
Add check in tee_shm_put to fix it.
panic log:
Unable to handle kernel paging request at virtual address 0000000000100cca
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000
[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----
6.6.0-39-generic #38
Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07
Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0
10/26/2022
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : tee_shm_put+0x24/0x188
lr : tee_shm_free+0x14/0x28
sp : ffff001f98f9faf0
x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000
x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048
x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88
x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff
x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003
x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101
x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c
x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca
Call trace:
tee_shm_put+0x24/0x188
tee_shm_free+0x14/0x28
__optee_disable_shm_cache+0xa8/0x108
optee_shutdown+0x28/0x38
platform_shutdown+0x28/0x40
device_shutdown+0x144/0x2b0
kernel_power_off+0x3c/0x80
hibernate+0x35c/0x388
state_store+0x64/0x80
kobj_attr_store+0x14/0x28
sysfs_kf_write+0x48/0x60
kernfs_fop_write_iter+0x128/0x1c0
vfs_write+0x270/0x370
ksys_write+0x6c/0x100
__arm64_sys_write+0x20/0x30
invoke_syscall+0x4c/0x120
el0_svc_common.constprop.0+0x44/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x24/0x88
el0t_64_sync_handler+0x134/0x150
el0t_64_sync+0x14c/0x15
CVE-2025-39865
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: writeback: fix use-after-free in __mark_inode_dirty()
An use-after-free issue occurred when __mark_inode_dirty() get the
bdi_writeback that was in the progress of switching.
CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1
......
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __mark_inode_dirty+0x124/0x418
lr : __mark_inode_dirty+0x118/0x418
sp : ffffffc08c9dbbc0
........
Call trace:
__mark_inode_dirty+0x124/0x418
generic_update_time+0x4c/0x60
file_modified+0xcc/0xd0
ext4_buffered_write_iter+0x58/0x124
ext4_file_write_iter+0x54/0x704
vfs_write+0x1c0/0x308
ksys_write+0x74/0x10c
__arm64_sys_write+0x1c/0x28
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0xc0/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x40/0xe4
el0t_64_sync_handler+0x120/0x12c
el0t_64_sync+0x194/0x198
Root cause is:
systemd-random-seed kworker
----------------------------------------------------------------------
___mark_inode_dirty inode_switch_wbs_work_fn
spin_lock(&inode->i_lock);
inode_attach_wb
locked_inode_to_wb_and_lock_list
get inode->i_wb
spin_unlock(&inode->i_lock);
spin_lock(&wb->list_lock)
spin_lock(&inode->i_lock)
inode_io_list_move_locked
spin_unlock(&wb->list_lock)
spin_unlock(&inode->i_lock)
spin_lock(&old_wb->list_lock)
inode_do_switch_wbs
spin_lock(&inode->i_lock)
inode->i_wb = new_wb
spin_unlock(&inode->i_lock)
spin_unlock(&old_wb->list_lock)
wb_put_many(old_wb, nr_switched)
cgwb_release
old wb released
wb_wakeup_delayed() accesses wb,
then trigger the use-after-free
issue
Fix this race condition by holding inode spinlock until
wb_wakeup_delayed() finished.
CVE-2025-39866
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: edma: Fix memory allocation size for queue_priority_map
Fix a critical memory allocation bug in edma_setup_from_hw() where
queue_priority_map was allocated with insufficient memory. The code
declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),
but allocated memory using sizeof(s8) instead of the correct size.
This caused out-of-bounds memory writes when accessing:
queue_priority_map[i][0] = i;
queue_priority_map[i][1] = i;
The bug manifested as kernel crashes with "Oops - undefined instruction"
on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the
memory corruption triggered kernel hardening features on Clang.
Change the allocation to use sizeof(*queue_priority_map) which
automatically gets the correct size for the 2D array structure.
CVE-2025-39869
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()
The function of_phy_find_device may return NULL, so we need to take
care before dereferencing phy_dev.
CVE-2025-39876
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix recursive semaphore deadlock in fiemap call
syzbot detected a OCFS2 hang due to a recursive semaphore on a
FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.
context_switch kernel/sched/core.c:5357 [inline]
__schedule+0x1798/0x4cc0 kernel/sched/core.c:6961
__schedule_loop kernel/sched/core.c:7043 [inline]
schedule+0x165/0x360 kernel/sched/core.c:7058
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115
rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185
__down_write_common kernel/locking/rwsem.c:1317 [inline]
__down_write kernel/locking/rwsem.c:1326 [inline]
down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591
ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142
do_page_mkwrite+0x14d/0x310 mm/memory.c:3361
wp_page_shared mm/memory.c:3762 [inline]
do_wp_page+0x268d/0x5800 mm/memory.c:3981
handle_pte_fault mm/memory.c:6068 [inline]
__handle_mm_fault+0x1033/0x5440 mm/memory.c:6195
handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364
do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387
handle_page_fault arch/x86/mm/fault.c:1476 [inline]
exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]
RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]
RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]
RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26
Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89
f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 <f3> a4 0f
1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41
RSP: 0018:ffffc9000403f950 EFLAGS: 00050256
RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038
RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060
RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42
R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098
R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060
copy_to_user include/linux/uaccess.h:225 [inline]
fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145
ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806
ioctl_fiemap fs/ioctl.c:220 [inline]
do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532
__do_sys_ioctl fs/ioctl.c:596 [inline]
__se_sys_ioctl+0x82/0x170 fs/ioctl.c:584
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5f13850fd9
RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9
RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004
RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0
R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b
ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since
v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the
extent list of this running mmap executable. The user supplied buffer to
hold the fiemap information page faults calling ocfs2_page_mkwrite() which
will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same
semaphore. This recursive semaphore will hold filesystem locks and causes
a hang of the fileystem.
The ip_alloc_sem protects the inode extent list and size. Release the
read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()
and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock
on the last extent but simplifies the error path.
CVE-2025-39885
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2025-39898
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path
If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration
later than the first, the error path wants to free the IRQs requested
so far. However, it uses the wrong dev_id argument for free_irq(), so
it does not free the IRQs correctly and instead triggers the warning:
Trying to free already-free IRQ 173
WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0
Modules linked in: i40e(+) [...]
CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
Hardware name: [...]
RIP: 0010:__free_irq+0x192/0x2c0
[...]
Call Trace:
<TASK>
free_irq+0x32/0x70
i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]
i40e_vsi_request_irq+0x79/0x80 [i40e]
i40e_vsi_open+0x21f/0x2f0 [i40e]
i40e_open+0x63/0x130 [i40e]
__dev_open+0xfc/0x210
__dev_change_flags+0x1fc/0x240
netif_change_flags+0x27/0x70
do_setlink.isra.0+0x341/0xc70
rtnl_newlink+0x468/0x860
rtnetlink_rcv_msg+0x375/0x450
netlink_rcv_skb+0x5c/0x110
netlink_unicast+0x288/0x3c0
netlink_sendmsg+0x20d/0x430
____sys_sendmsg+0x3a2/0x3d0
___sys_sendmsg+0x99/0xe0
__sys_sendmsg+0x8a/0xf0
do_syscall_64+0x82/0x2c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
[...]
</TASK>
---[ end trace 0000000000000000 ]---
Use the same dev_id for free_irq() as for request_irq().
I tested this with inserting code to fail intentionally.
CVE-2025-39911
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees
When we don't have a clock specified in the device tree, we have no way to
ensure the BAM is on. This is often the case for remotely-controlled or
remotely-powered BAM instances. In this case, we need to read num-channels
from the DT to have all the necessary information to complete probing.
However, at the moment invalid device trees without clock and without
num-channels still continue probing, because the error handling is missing
return statements. The driver will then later try to read the number of
channels from the registers. This is unsafe, because it relies on boot
firmware and lucky timing to succeed. Unfortunately, the lack of proper
error handling here has been abused for several Qualcomm SoCs upstream,
causing early boot crashes in several situations [1, 2].
Avoid these early crashes by erroring out when any of the required DT
properties are missing. Note that this will break some of the existing DTs
upstream (mainly BAM instances related to the crypto engine). However,
clearly these DTs have never been tested properly, since the error in the
kernel log was just ignored. It's safer to disable the crypto engine for
these broken DTBs.
[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
CVE-2025-39923
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path
During tests of another unrelated patch I was able to trigger this
error: Objects remaining on __kmem_cache_shutdown()
CVE-2025-39929
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Set merge to zero early in af_alg_sendmsg
If an error causes af_alg_sendmsg to abort, ctx->merge may contain
a garbage value from the previous loop. This may then trigger a
crash on the next entry into af_alg_sendmsg when it attempts to do
a merge that can't be done.
Fix this by setting ctx->merge to zero near the start of the loop.
CVE-2025-39931
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
cnic: Fix use-after-free bugs in cnic_delete_task
The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),
which does not guarantee that the delayed work item 'delete_task' has
fully completed if it was already running. Additionally, the delayed work
item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only
blocks and waits for work items that were already queued to the
workqueue prior to its invocation. Any work items submitted after
flush_workqueue() is called are not included in the set of tasks that the
flush operation awaits. This means that after the cyclic work items have
finished executing, a delayed work item may still exist in the workqueue.
This leads to use-after-free scenarios where the cnic_dev is deallocated
by cnic_free_dev(), while delete_task remains active and attempt to
dereference cnic_dev in cnic_delete_task().
A typical race condition is illustrated below:
CPU 0 (cleanup) | CPU 1 (delayed work callback)
cnic_netdev_event() |
cnic_stop_hw() | cnic_delete_task()
cnic_cm_stop_bnx2x_hw() | ...
cancel_delayed_work() | /* the queue_delayed_work()
flush_workqueue() | executes after flush_workqueue()*/
| queue_delayed_work()
cnic_free_dev(dev)//free | cnic_delete_task() //new instance
| dev = cp->dev; //use
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the cyclic delayed work item is properly canceled and that any
ongoing execution of the work item completes before the cnic_dev is
deallocated. Furthermore, since cancel_delayed_work_sync() uses
__flush_work(work, true) to synchronously wait for any currently
executing instance of the work item to finish, the flush_workqueue()
becomes redundant and should be removed.
This bug was identified through static analysis. To reproduce the issue
and validate the fix, I simulated the cnic PCI device in QEMU and
introduced intentional delays - such as inserting calls to ssleep()
within the cnic_delete_task() function - to increase the likelihood
of triggering the bug.
CVE-2025-39945
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
qed: Don't collect too many protection override GRC elements
In the protection override dump path, the firmware can return far too
many GRC elements, resulting in attempting to write past the end of the
previously-kmalloc'ed dump buffer.
This will result in a kernel panic with reason:
BUG: unable to handle kernel paging request at ADDRESS
where "ADDRESS" is just past the end of the protection override dump
buffer. The start address of the buffer is:
p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf
and the size of the buffer is buf_size in the same data structure.
The panic can be arrived at from either the qede Ethernet driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc02662ed [qed]
qed_dbg_protection_override_dump at ffffffffc0267792 [qed]
qed_dbg_feature at ffffffffc026aa8f [qed]
qed_dbg_all_data at ffffffffc026b211 [qed]
qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]
devlink_health_do_dump at ffffffff82497f61
devlink_health_report at ffffffff8249cf29
qed_report_fatal_error at ffffffffc0272baf [qed]
qede_sp_task at ffffffffc045ed32 [qede]
process_one_work at ffffffff81d19783
or the qedf storage driver path:
[exception RIP: qed_grc_dump_addr_range+0x108]
qed_protection_override_dump at ffffffffc068b2ed [qed]
qed_dbg_protection_override_dump at ffffffffc068c792 [qed]
qed_dbg_feature at ffffffffc068fa8f [qed]
qed_dbg_all_data at ffffffffc0690211 [qed]
qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]
devlink_health_do_dump at ffffffff8aa95e51
devlink_health_report at ffffffff8aa9ae19
qed_report_fatal_error at ffffffffc0697baf [qed]
qed_hw_err_notify at ffffffffc06d32d7 [qed]
qed_spq_post at ffffffffc06b1011 [qed]
qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]
qedf_cleanup_fcport at ffffffffc05e7597 [qedf]
qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]
fc_rport_work at ffffffffc02da715 [libfc]
process_one_work at ffffffff8a319663
Resolve this by clamping the firmware's return value to the maximum
number of legal elements the firmware should return.
CVE-2025-39949
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().
syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
in the TCP_ESTABLISHED state. [0]
syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:
1. accept()
2. connect(AF_UNSPEC)
3. connect() to another destination
As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.
Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.
Let's call reqsk_fastopen_remove() in tcp_disconnect().
[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
Call Trace:
<IRQ>
tcp_write_timer (net/ipv4/tcp_timer.c:738)
call_timer_fn (kernel/time/timer.c:1747)
__run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
__walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
tmigr_handle_remote (kernel/time/timer_migration.c:1096)
handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
</IRQ>
CVE-2025-39955
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fbcon: fix integer overflow in fbcon_do_set_font
Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
size calculations could overflow when handling user-controlled font
parameters.
The vulnerabilities occur when:
1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount
multiplication with user-controlled values that can overflow.
2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow
3. This results in smaller allocations than expected, leading to buffer
overflows during font data copying.
Add explicit overflow checking using check_mul_overflow() and
check_add_overflow() kernel helpers to safety validate all size
calculations before allocation.
CVE-2025-39967
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: add max boundary check for VF filters
There is no check for max filters that VF can request. Add it.
CVE-2025-39968
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
low
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix input validation logic for action_meta
Fix condition to check 'greater or equal' to prevent OOB dereference.
CVE-2025-39970
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix idx validation in config queues msg
Ensure idx is within range of active/initialized TCs when iterating over
vf->ch[idx] in i40e_vc_config_queues_msg().
CVE-2025-39971
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix idx validation in i40e_validate_queue_map
Ensure idx is within range of active/initialized TCs when iterating over
vf->ch[idx] in i40e_validate_queue_map().
CVE-2025-39972
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
i40e: add validation for ring_len param
The `ring_len` parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.
To address this, introduce an upper boundary check for both Tx and Rx
queue lengths. The maximum number of descriptors supported by the
hardware is 8k-32.
Additionally, enforce alignment constraints: Tx rings must be a multiple
of 8, and Rx rings must be a multiple of 32.
CVE-2025-39973
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free
The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at
removal") patched a UAF issue caused by the error timer.
However, because the error timer kill added in this patch occurs after the
endpoint delete, a race condition to UAF still occurs, albeit rarely.
Additionally, since kill-cleanup for urb is also missing, freed memory can
be accessed in interrupt context related to urb, which can cause UAF.
Therefore, to prevent this, error timer and urb must be killed before
freeing the heap memory.
CVE-2025-39997
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
scsi: mvsas: Fix use-after-free bugs in mvs_work_queue
During the detaching of Marvell's SAS/SATA controller, the original code
calls cancel_delayed_work() in mvs_free() to cancel the delayed work
item mwq->work_q. However, if mwq->work_q is already running, the
cancel_delayed_work() may fail to cancel it. This can lead to
use-after-free scenarios where mvs_free() frees the mvs_info while
mvs_work_queue() is still executing and attempts to access the
already-freed mvs_info.
A typical race condition is illustrated below:
CPU 0 (remove) | CPU 1 (delayed work callback)
mvs_pci_remove() |
mvs_free() | mvs_work_queue()
cancel_delayed_work() |
kfree(mvi) |
| mvi-> // UAF
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the delayed work item is properly canceled and any executing
delayed work item completes before the mvs_info is deallocated.
This bug was found by static analysis.
CVE-2025-40001
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ipvs: Defer ip_vs_ftp unregister during netns cleanup
On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp
before connections with valid cp->app pointers are flushed, leading to a
use-after-free.
Fix this by introducing a global `exiting_module` flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.
CVE-2025-40018
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix double req put in p9_fd_cancelled
Syzkaller reports a KASAN issue as below:
general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]
CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:__list_del include/linux/list.h:114 [inline]
RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]
RIP: 0010:list_del include/linux/list.h:148 [inline]
RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734
Call Trace:
<TASK>
p9_client_flush+0x351/0x440 net/9p/client.c:614
p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734
p9_client_version net/9p/client.c:920 [inline]
p9_client_create+0xb51/0x1240 net/9p/client.c:1027
v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126
legacy_get_tree+0x108/0x220 fs/fs_context.c:632
vfs_get_tree+0x8e/0x300 fs/super.c:1573
do_new_mount fs/namespace.c:3056 [inline]
path_mount+0x6a6/0x1e90 fs/namespace.c:3386
do_mount fs/namespace.c:3399 [inline]
__do_sys_mount fs/namespace.c:3607 [inline]
__se_sys_mount fs/namespace.c:3584 [inline]
__x64_sys_mount+0x283/0x300 fs/namespace.c:3584
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
This happens because of a race condition between:
- The 9p client sending an invalid flush request and later cleaning it up;
- The 9p client in p9_read_work() canceled all pending requests.
Thread 1 Thread 2
...
p9_client_create()
...
p9_fd_create()
...
p9_conn_create()
...
// start Thread 2
INIT_WORK(&m->rq, p9_read_work);
p9_read_work()
...
p9_client_rpc()
...
...
p9_conn_cancel()
...
spin_lock(&m->req_lock);
...
p9_fd_cancelled()
...
...
spin_unlock(&m->req_lock);
// status rewrite
p9_client_cb(m->client, req, REQ_STATUS_ERROR)
// first remove
list_del(&req->req_list);
...
spin_lock(&m->req_lock)
...
// second remove
list_del(&req->req_list);
spin_unlock(&m->req_lock)
...
Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in
p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem
client where the req_list could be deleted simultaneously by both
p9_read_work and p9_fd_cancelled functions, but for the case where req->status
equals REQ_STATUS_RCVD.
Update the check for req->status in p9_fd_cancelled to skip processing not
just received requests, but anything that is not SENT, as whatever
changed the state from SENT also removed the request from its list.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
[updated the check from status == RECV || status == ERROR to status != SENT]
CVE-2025-40027
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: check the return value of pinmux_ops::get_function_name()
While the API contract in docs doesn't specify it explicitly, the
generic implementation of the get_function_name() callback from struct
pinmux_ops - pinmux_generic_get_function_name() - can fail and return
NULL. This is already checked in pinmux_check_ops() so add a similar
check in pinmux_func_name_to_selector() instead of passing the returned
pointer right down to strcmp() where the NULL can get dereferenced. This
is normal operation when adding new pinfunctions.
CVE-2025-40030
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------
[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!
[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)
[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace:
[ 44.617926] <TASK>
[ 44.619284] userfaultfd_release+0xef/0x1b0
[ 44.620976] __fput+0x3f9/0xb60
[ 44.621240] fput_close_sync+0x110/0x210
[ 44.622222] __x64_sys_close+0x8f/0x120
[ 44.622530] do_syscall_64+0x5b/0x2f0
[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during
userfaultfd_release_all(). Specifically, a VMA which has a valid pointer
to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise()
with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,
it accidentally clears all flags stored in the upper 32 bits of
vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and
int are 32-bit wide. This setup causes the following mishap during the &=
~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000.
After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then
promoted to unsigned long before the & operation. This promotion fills
upper 32 bits with leading 0s, as we're doing unsigned conversion (and
even for a signed conversion, this wouldn't help as the leading bit is 0).
& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff
instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears
the upper 32-bits of its value.
Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the
BIT() macro.
Note: other VM_* flags are not affected: This only happens to the
VM_MERGEABLE flag, as the other VM_* flags are all constants of type int
and after ~ operation, they end up with leading 1 and are thus converted
to unsigned long with leading 1s.
Note 2:
After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is
no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
CVE-2025-40040
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
fs: udf: fix OOB read in lengthAllocDescs handling
When parsing Allocation Extent Descriptor, lengthAllocDescs comes from
on-disk data and must be validated against the block size. Crafted or
corrupted images may set lengthAllocDescs so that the total descriptor
length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,
leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and
trigger a KASAN use-after-free read.
BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309
CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261
udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179
extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46
udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106
udf_release_file+0xc1/0x120 fs/udf/file.c:185
__fput+0x23f/0x880 fs/file_table.c:431
task_work_run+0x24f/0x310 kernel/task_work.c:239
exit_task_work include/linux/task_work.h:43 [inline]
do_exit+0xa2f/0x28e0 kernel/exit.c:939
do_group_exit+0x207/0x2c0 kernel/exit.c:1088
__do_sys_exit_group kernel/exit.c:1099 [inline]
__se_sys_exit_group kernel/exit.c:1097 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097
x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Validate the computed total length against epos->bh->b_size.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-40044
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Let userspace take care of interrupt mask
Remove the logic to set interrupt mask by default in uio_hv_generic
driver as the interrupt mask value is supposed to be controlled
completely by the user space. If the mask bit gets changed
by the driver, concurrently with user mode operating on the ring,
the mask bit may be set when it is supposed to be clear, and the
user-mode driver will miss an interrupt which will cause a hang.
For eg- when the driver sets inbound ring buffer interrupt mask to 1,
the host does not interrupt the guest on the UIO VMBus channel.
However, setting the mask does not prevent the host from putting a
message in the inbound ring buffer. So let's assume that happens,
the host puts a message into the ring buffer but does not interrupt.
Subsequently, the user space code in the guest sets the inbound ring
buffer interrupt mask to 0, saying “Hey, I'm ready for interrupts”.
User space code then calls pread() to wait for an interrupt.
Then one of two things happens:
* The host never sends another message. So the pread() waits forever.
* The host does send another message. But because there's already a
message in the ring buffer, it doesn't generate an interrupt.
This is the correct behavior, because the host should only send an
interrupt when the inbound ring buffer transitions from empty to
not-empty. Adding an additional message to a ring buffer that is not
empty is not supposed to generate an interrupt on the guest.
Since the guest is waiting in pread() and not removing messages from
the ring buffer, the pread() waits forever.
This could be easily reproduced in hv_fcopy_uio_daemon if we delay
setting interrupt mask to 0.
Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
there's a race condition. Once user space empties the inbound ring
buffer, but before user space sets interrupt_mask to 0, the host could
put another message in the ring buffer but it wouldn't interrupt.
Then the next pread() would hang.
Fix these by removing all instances where interrupt_mask is changed,
while keeping the one in set_event() unchanged to enable userspace
control the interrupt mask by writing 0/1 to /dev/uioX.
CVE-2025-40048
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: fix uninit-value in squashfs_get_parent
Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.
This is caused by open_by_handle_at() being called with a file handle
containing an invalid parent inode number. In particular the inode number
is that of a symbolic link, rather than a directory.
Squashfs_get_parent() gets called with that symbolic link inode, and
accesses the parent member field.
unsigned int parent_ino = squashfs_i(inode)->parent;
Because non-directory inodes in Squashfs do not have a parent value, this
is uninitialised, and this causes an uninitialised value access.
The fix is to initialise parent with the invalid inode 0, which will cause
an EINVAL error to be returned.
Regular inodes used to share the parent field with the block_list_start
field. This is removed in this commit to enable the parent field to
contain the invalid inode number 0.
CVE-2025-40049
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix double free in user_cluster_connect()
user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then
the error handling frees "lc" a second time. Set "lc" to NULL on this
path to avoid a double free.
CVE-2025-40055
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
pps: fix warning in pps_register_cdev when register device fail
Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error
handling in __video_register_device()"), the release hook should be set
before device_register(). Otherwise, when device_register() return error
and put_device() try to callback the release function, the below warning
may happen.
------------[ cut here ]------------
WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567
Modules linked in:
CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE
RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567
Call Trace:
<TASK>
kobject_cleanup+0x136/0x410 lib/kobject.c:689
kobject_release lib/kobject.c:720 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0xe9/0x130 lib/kobject.c:737
put_device+0x24/0x30 drivers/base/core.c:3797
pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402
pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108
pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57
tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432
tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563
tiocsetd drivers/tty/tty_io.c:2429 [inline]
tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:598 [inline]
__se_sys_ioctl fs/ioctl.c:584 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),
pps_register_cdev() call device_create() to create pps->dev, which will
init dev->release to device_create_release(). Now the comment is outdated,
just remove it.
Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed
in pps_register_source() to avoid a double free in the failure case.
CVE-2025-40070
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
bpf: Explicitly check accesses to bpf_sock_addr
Syzkaller found a kernel warning on the following sock_addr program:
0: r0 = 0
1: r2 = *(u32 *)(r1 +60)
2: exit
which triggers:
verifier bug: error during ctx access conversion (0)
This is happening because offset 60 in bpf_sock_addr corresponds to an
implicit padding of 4 bytes, right after msg_src_ip4. Access to this
padding isn't rejected in sock_addr_is_valid_access and it thus later
fails to convert the access.
This patch fixes it by explicitly checking the various fields of
bpf_sock_addr in sock_addr_is_valid_access.
I checked the other ctx structures and is_valid_access functions and
didn't find any other similar cases. Other cases of (properly handled)
padding are covered in new tests in a subsequent patch.
CVE-2025-40078
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290
CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x5f0 mm/kasan/report.c:482
kasan_report+0xca/0x100 mm/kasan/report.c:595
hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738
vfs_listxattr+0xbe/0x140 fs/xattr.c:493
listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe0e9fae16d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3
RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000
RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000
</TASK>
Allocated by task 14290:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4333 [inline]
__kmalloc_noprof+0x219/0x540 mm/slub.c:4345
kmalloc_noprof include/linux/slab.h:909 [inline]
hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21
hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697
vfs_listxattr+0xbe/0x140 fs/xattr.c:493
listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
When hfsplus_uni2asc is called from hfsplus_listxattr,
it actually passes in a struct hfsplus_attr_unistr*.
The size of the corresponding structure is different from that of hfsplus_unistr,
so the previous fix (94458781aee6) is insufficient.
The pointer on the unicode buffer is still going beyond the allocated memory.
This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and
hfsplus_uni2asc_str to process two unicode buffers,
struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.
When ustrlen value is bigger than the allocated memory size,
the ustrlen value is limited to an safe size.
CVE-2025-40082
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix null-deref in agg_dequeue
To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)
when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return
value before using it, similar to the existing approach in sch_hfsc.c.
To avoid code duplication, the following changes are made:
1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static
inline function.
2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to
include/net/pkt_sched.h so that sch_qfq can reuse it.
3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.
CVE-2025-40083
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()
The hfsplus_strcasecmp() logic can trigger the issue:
[ 117.317703][ T9855] ==================================================================
[ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490
[ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855
[ 117.319577][ T9855]
[ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)
[ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 117.319783][ T9855] Call Trace:
[ 117.319785][ T9855] <TASK>
[ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0
[ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0
[ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10
[ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0
[ 117.319816][ T9855] ? lock_release+0x4b/0x3e0
[ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40
[ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0
[ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0
[ 117.319842][ T9855] print_report+0x17e/0x7e0
[ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0
[ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0
[ 117.319862][ T9855] ? __phys_addr+0xd3/0x180
[ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490
[ 117.319876][ T9855] kasan_report+0x147/0x180
[ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490
[ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490
[ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10
[ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0
[ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470
[ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10
[ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10
[ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10
[ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510
[ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10
[ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10
[ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510
[ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0
[ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120
[ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890
[ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10
[ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0
[ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80
[ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10
[ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100
[ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150
[ 117.320034][ T9855] __lookup_slow+0x297/0x3d0
[ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10
[ 117.320045][ T9855] ? down_read+0x1ad/0x2e0
[ 117.320055][ T9855] lookup_slow+0x53/0x70
[ 117.320065][ T9855] walk_component+0x2f0/0x430
[ 117.320073][ T9855] path_lookupat+0x169/0x440
[ 117.320081][ T9855] filename_lookup+0x212/0x590
[ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10
[ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290
[ 117.320105][ T9855] ? getname_flags+0x1e5/0x540
[ 117.320112][ T9855] user_path_at+0x3a/0x60
[ 117.320117][ T9855] __x64_sys_umount+0xee/0x160
[ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10
[ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0
[ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0
[ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0
[ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07
[ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08
[ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202
---truncated---
CVE-2025-40088
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
net/ip6_tunnel: Prevent perpetual tunnel growth
Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.
While ipv4 tunnel headroom adjustment growth was limited in
commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),
ipv6 tunnel yet increases the headroom without any ceiling.
Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.
Credits to Francesco Ruggeri, who was originally debugging this issue
and wrote local Arista-specific patch and a reproducer.
CVE-2025-40173
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().
syzbot reported the splat below in tcp_conn_request(). [0]
If a listener is close()d while a TFO socket is being processed in
tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk
and calls inet_child_forget(), which calls tcp_disconnect() for the
TFO socket.
After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),
where reqsk_put() is called due to !reqsk->sk.
Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the
last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the
drop_and_free label causes the refcount underflow for the listener
and double-free of the reqsk.
Let's remove reqsk_fastopen_remove() in tcp_conn_request().
Note that other callers make sure tp->fastopen_rsk is not NULL.
[0]:
refcount_t: underflow; use-after-free.
WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)
Modules linked in:
CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)
Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6
RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246
RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900
RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280
RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280
R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100
R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8
FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0
Call Trace:
<IRQ>
tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301)
tcp_rcv_state_process (net/ipv4/tcp_input.c:6708)
tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670)
tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906)
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438)
ip6_input (net/ipv6/ip6_input.c:500)
ipv6_rcv (net/ipv6/ip6_input.c:311)
__netif_receive_skb (net/core/dev.c:6104)
process_backlog (net/core/dev.c:6456)
__napi_poll (net/core/dev.c:7506)
net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696)
handle_softirqs (kernel/softirq.c:579)
do_softirq (kernel/softirq.c:480)
</IRQ>
CVE-2025-40186
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
sctp: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time.
Use the appropriate helper function for this.
CVE-2025-40204
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
important
In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid potential out-of-bounds in btrfs_encode_fh()
The function btrfs_encode_fh() does not properly account for the three
cases it handles.
Before writing to the file handle (fh), the function only returns to the
user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or
BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).
However, when a parent exists and the root ID of the parent and the
inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT
(10 dwords, 40 bytes).
If *max_len is not large enough, this write goes out of bounds because
BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than
BTRFS_FID_SIZE_CONNECTABLE originally returned.
This results in an 8-byte out-of-bounds write at
fid->parent_root_objectid = parent_root_id.
A previous attempt to fix this issue was made but was lost.
https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/
Although this issue does not seem to be easily triggerable, it is a
potential memory corruption bug that should be fixed. This patch
resolves the issue by ensuring the function returns the appropriate size
for all three cases and validates that *max_len is large enough before
writing any data.
CVE-2025-40205
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
In the Linux kernel, the following vulnerability has been resolved:
x86/vmscape: Add conditional IBPB mitigation
VMSCAPE is a vulnerability that exploits insufficient branch predictor
isolation between a guest and a userspace hypervisor (like QEMU). Existing
mitigations already protect kernel/KVM from a malicious guest. Userspace
can additionally be protected by flushing the branch predictors after a
VMexit.
Since it is the userspace that consumes the poisoned branch predictors,
conditionally issue an IBPB after a VMexit and before returning to
userspace. Workloads that frequently switch between hypervisor and
userspace will incur the most overhead from the new IBPB.
This new IBPB is not integrated with the existing IBPB sites. For
instance, a task can use the existing speculation control prctl() to
get an IBPB at context switch time. With this implementation, the
IBPB is doubled up: one at context switch and another before running
userspace.
The intent is to integrate and optimize these cases post-embargo.
[ dhansen: elaborate on suboptimal IBPB solution ]
CVE-2025-40300
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:kernel-default-4.12.14-122.283.1
moderate
Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.
This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.
CVE-2025-40778
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:bind-utils-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libbind9-161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libdns1110-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libirs161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisc1107-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccc161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libisccfg163-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:liblwres161-9.11.22-3.65.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-bind-9.11.22-3.65.1
important
Perl threads have a working directory race condition where file operations may target unintended paths.
If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running.
This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.
The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6
CVE-2025-40909
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:perl-5.18.2-12.29.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:perl-base-5.18.2-12.29.1
moderate
Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.
You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.
Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.
Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
CVE-2025-4330
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.
CVE-2025-4373
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
moderate
When using a TarFile.errorlevel = 0 and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0 in affected versions is that the member would still be extracted and not skipped.
CVE-2025-4435
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
There is an issue in CPython when using `bytes.decode("unicode_escape", error="ignore|replace")`. If you are not using the "unicode_escape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.
CVE-2025-4516
moderate
Allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data".
You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information.
Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.
Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.
CVE-2025-4517
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
important
A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original's privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process.
A SUID binary or process has a special type of permission, which allows the process to run with the file owner's permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original's SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality.
CVE-2025-4598
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libsystemd0-228-157.72.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libudev1-228-157.72.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:systemd-228-157.72.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:systemd-sysvinit-228-157.72.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:udev-228-157.72.1
moderate
For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.
CVE-2025-46802
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:screen-4.0.4-23.9.1
moderate
net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20.
CVE-2025-46836
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:net-tools-1.60-765.15.1
moderate
ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication.
CVE-2025-47268
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:iputils-s20161105-11.12.1
moderate
setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue.
CVE-2025-47273
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-setuptools-40.6.2-4.27.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-setuptools-40.6.2-4.27.1
important
There's a vulnerability in the libssh package where when a libssh consumer passes in an unexpectedly large input buffer to ssh_get_fingerprint_hash() function. In such cases the bin_to_base64() function can experience an integer overflow leading to a memory under allocation, when that happens it's possible that the program perform out of bounds write leading to a heap corruption.
This issue affects only 32-bits builds of libssh.
CVE-2025-4877
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
A vulnerability was found in libssh, where an uninitialized variable exists under certain conditions in the privatekey_from_file() function. This flaw can be triggered if the file specified by the filename doesn't exist and may lead to possible signing failures or heap corruption.
CVE-2025-4878
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).
CVE-2025-48964
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:iputils-s20161105-11.12.1
moderate
A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the <sch:name path="..."/> schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.
CVE-2025-49794
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
important
A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.
CVE-2025-49796
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
important
urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
CVE-2025-50181
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-urllib3-1.25.10-3.43.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-urllib3-1.25.10-3.43.1
moderate
A stack buffer overflow was found in Internationl components for unicode (ICU ). While running the genrb binary, the 'subtag' struct overflowed at the SRBRoot::addTag function. This issue may lead to memory corruption and local arbitrary code execution.
CVE-2025-5222
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libicu52_1-52.1-8.16.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libicu52_1-data-52.1-8.16.1
important
A flaw was found in GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.
CVE-2025-5278
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:coreutils-8.25-13.19.1
moderate
A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.
CVE-2025-5318
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success-the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability.
CVE-2025-5372
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
important
Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.
CVE-2025-53905
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.
CVE-2025-53906
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
CVE-2025-54771
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1400, When processing nested tuples in Vim script, an error during evaluation can trigger a use-after-free in Vim's internal tuple reference management. Specifically, the tuple_unref() function may access already freed memory due to improper lifetime handling, leading to memory corruption. The exploit requires direct user interaction, as the script must be explicitly executed within Vim. This issue has been patched in version 9.1.1400.
CVE-2025-55157
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.
CVE-2025-55158
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-9.1.1629-17.54.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:vim-data-common-9.1.1629-17.54.1
moderate
OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue.
CVE-2025-58060
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:cups-libs-1.7.5-20.57.1
important
OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, an unsafe deserialization and validation of printer attributes causes null dereference in the libcups library. This is a remote DoS vulnerability available in local subnet in default configurations. It can cause the cups & cups-browsed to crash, on all the machines in local network who are listening for printers (so by default for all regular linux machines). On systems where the vulnerability CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was not fixed, and the firewall on the machine does not reject incoming communication to IPP port, and the machine is set to be available to public internet, attack vector "Network" is possible. The current versions of CUPS and cups-browsed projects have the attack vector "Adjacent" in their default configurations. Version 2.4.13 contains a patch for CVE-2025-58364.
CVE-2025-58364
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:cups-libs-1.7.5-20.57.1
moderate
libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.
CVE-2025-59375
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:expat-2.7.1-21.46.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libexpat1-2.7.1-21.46.1
important
A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allow_active" user. The highest risk is that the attacker can then perform all allow_active yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations.
CVE-2025-6018
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:pam-1.1.8-24.77.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:pam-config-0.89-5.8.1
important
A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.
CVE-2025-6021
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
important
The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.
CVE-2025-6069
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
If the value passed to os.path.expandvars() is user-controlled a
performance degradation is possible when expanding environment
variables.
CVE-2025-6075
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
low
A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.
CVE-2025-61661
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.
CVE-2025-61662
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.
CVE-2025-61663
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.
CVE-2025-61664
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-i386-pc-2.02-193.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:grub2-x86_64-efi-2.02-193.1
moderate
A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.
CVE-2025-6170
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
moderate
OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a user in the lpadmin group can use the cups web ui to change the config and insert a malicious line. Then the cupsd process which runs as root will parse the new config and cause an out-of-bound write. This issue has been patched in version 2.4.15.
CVE-2025-61915
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:cups-libs-1.7.5-20.57.1
moderate
ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)
CVE-2025-61984
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:openssh-7.2p2-81.34.1
moderate
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.
CVE-2025-64505
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
moderate
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.
CVE-2025-64506
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
moderate
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.
CVE-2025-64720
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
moderate
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.
CVE-2025-65018
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
moderate
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.
CVE-2025-66293
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
important
There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.
CVE-2025-6965
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libsqlite3-0-3.50.2-9.41.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:sqlite3-tcl-3.50.2-9.41.1
important
A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.
CVE-2025-7039
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
moderate
A flaw was found in libxslt where the attribute type, atype, flags are modified in a way that corrupts internal memory management. When XSLT functions, such as the key() process, result in tree fragments, this corruption prevents the proper cleanup of ID attributes. As a result, the system may access freed memory, causing crashes or enabling attackers to trigger heap corruption.
CVE-2025-7425
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
important
A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.
CVE-2025-7519
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpolkit0-0.113-5.30.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:polkit-0.113-5.30.1
moderate
A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.
CVE-2025-8114
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
moderate
There is a defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives.
This vulnerability can be mitigated by including the following patch after importing the “tarfile” module: https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1
CVE-2025-8194
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
moderate
A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.
CVE-2025-8277
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libssh4-0.9.8-3.18.1
low
The 'zipfile' module would not check the validity of the ZIP64 End of
Central Directory (EOCD) Locator record offset value would not be used to
locate the ZIP64 EOCD record, instead the ZIP64 EOCD record would be
assumed to be the previous record in the ZIP archive. This could be abused
to create ZIP archives that are handled differently by the 'zipfile' module
compared to other ZIP implementations.
Remediation maintains this behavior, but checks that the offset specified
in the ZIP64 EOCD Locator record matches the expected value.
CVE-2025-8291
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python-2.7.18-33.56.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:python3-3.4.10-25.169.1
low
A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."
CVE-2025-8732
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
low
1. A cookie is set using the `secure` keyword for `https://target`
2. curl is redirected to or otherwise made to speak with `http://target` (same
hostname, but using clear text HTTP) using the same cookie set
3. The same cookie name is set - but with just a slash as path (`path=\"/\",`).
Since this site is not secure, the cookie *should* just be ignored.
4. A bug in the path comparison logic makes curl read outside a heap buffer
boundary
The bug either causes a crash or it potentially makes the comparison come to
the wrong conclusion and lets the clear-text site override the contents of the
secure cookie, contrary to expectations and depending on the memory contents
immediately following the single-byte allocation that holds the path.
The presumed and correct behavior would be to plainly ignore the second set of
the cookie since it was already set as secure on a secure host so overriding
it on an insecure host should not be okay.
CVE-2025-9086
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:curl-8.0.1-11.114.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libcurl4-8.0.1-11.114.1
important
Issue summary: An application trying to decrypt CMS messages encrypted using
password based encryption can trigger an out-of-bounds read and write.
Impact summary: This out-of-bounds read may trigger a crash which leads to
Denial of Service for an application. The out-of-bounds write can cause
a memory corruption which can have various consequences including
a Denial of Service or Execution of attacker-supplied code.
Although the consequences of a successful exploit of this vulnerability
could be severe, the probability that the attacker would be able to
perform it is low. Besides, password based (PWRI) encryption support in CMS
messages is very rarely used. For that reason the issue was assessed as
Moderate severity according to our Security Policy.
The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this
issue, as the CMS implementation is outside the OpenSSL FIPS module
boundary.
CVE-2025-9230
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_0_0-1.0.2p-3.98.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libopenssl1_1-1.1.1d-2.119.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:openssl-1_0_0-1.0.2p-3.98.1
important
A flaw was found in Samba, in the vfs_streams_xattr module, where uninitialized heap memory could be written into alternate data streams. This allows an authenticated user to read residual memory content that may include sensitive data, resulting in an information disclosure vulnerability.
CVE-2025-9640
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:samba-client-libs-4.15.13+git.664.e8416d8d213-3.99.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:samba-libs-4.15.13+git.664.e8416d8d213-3.99.1
moderate
Uncontrolled recursion in XPath evaluation in libxml2 up to and including version 2.9.14 allows a local attacker to cause a stack overflow via crafted expressions. XPath processing functions `xmlXPathRunEval`, `xmlXPathCtxtCompile`, and `xmlXPathEvalExpr` were resetting recursion depth to zero before making potentially recursive calls. When such functions were called recursively this could allow for uncontrolled recursion and lead to a stack overflow. These functions now preserve recursion depth across recursive calls, allowing recursion depth to be controlled.
CVE-2025-9714
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libxml2-2-2.9.4-46.93.1
moderate
A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).
CVE-2026-0988
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:glib2-tools-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgio-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libglib-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgmodule-2_0-0-2.48.2-12.55.1
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libgobject-2_0-0-2.48.2-12.55.1
low
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function png_image_finish_read when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.
CVE-2026-22695
Public Cloud Image google/sles-12-sp5-byos-v20260125-x86-64:libpng16-16-1.6.8-15.15.1
moderate