n/a–n/a
  An issue was discovered in the IhisiServiceSmm module in Insyde InsydeH2O with kernel 5.2 before 05.28.42, 5.3 before 05.37.42, 5.4 before 05.45.39, 5.5 before 05.53.39, and 5.6 before 05.60.39 that could allow an attacker to modify UEFI variables. 2024-07-31 not yet calculated CVE-2023-28149
cve@mitre.org
  Apple–macOS
  This issue was addressed with improved checks. This issue is fixed in macOS Monterey 12.6.4, macOS Big Sur 11.7.5, macOS Ventura 13.3, iOS 16.4 and iPadOS 16.4. A sandboxed process may be able to circumvent sandbox restrictions. 2024-07-29 not yet calculated CVE-2023-40398
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  The issue was addressed with improved restriction of data container access. This issue is fixed in iOS 17 and iPadOS 17, macOS Sonoma 14. An app may be able to access Notes attachments. 2024-07-29 not yet calculated CVE-2023-42925
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sonoma 14. An app may be able to read sensitive location information. 2024-07-29 not yet calculated CVE-2023-42943
product-security@apple.com
  Apple–macOS
  This issue was addressed through improved state management. This issue is fixed in macOS Sonoma 14. A Wi-Fi password may not be deleted when activating a Mac in macOS Recovery. 2024-07-29 not yet calculated CVE-2023-42948
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed with improved data protection. This issue is fixed in iOS 17 and iPadOS 17, macOS Sonoma 14, watchOS 10, tvOS 17. An app may be able to access edited photos saved to a temporary directory. 2024-07-29 not yet calculated CVE-2023-42949
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 17 and iPadOS 17, macOS Sonoma 14, watchOS 10. An app may be able to read sensitive location information. 2024-07-29 not yet calculated CVE-2023-42957
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done 2024-07-29 not yet calculated CVE-2023-52887
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Only free buffer VA that is not NULL In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn’t do the check and triggered warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings. 2024-07-30 not yet calculated CVE-2023-52888
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Western Digital–WD Discovery
  WD Discovery versions prior to 5.0.589 contain a misconfiguration in the Node.js environment settings that could allow code execution by utilizing the ‘ELECTRON_RUN_AS_NODE’ environment variable. Any malicious application operating with standard user permissions can exploit this vulnerability, enabling code execution within WD Discovery application’s context. WD Discovery version 5.0.589 addresses this issue by disabling certain features and fuses in Electron. The attack vector for this issue requires the victim to have the WD Discovery app installed on their device. 2024-08-02 not yet calculated CVE-2024-22169
psirt@wdc.com
  n/a–n/a
  Weak password hashing using MD5 in funzioni.php in HotelDruid before 1.32 allows an attacker to obtain plaintext passwords from hash values. 2024-07-30 not yet calculated CVE-2024-23091
cve@mitre.org
cve@mitre.org
  Apple–macOS
  A logic issue was addressed with improved state management. This issue is fixed in macOS Monterey 12.7.6, macOS Sonoma 14.4, macOS Ventura 13.6.8. An attacker may be able to read information belonging to another user. 2024-07-29 not yet calculated CVE-2024-23261
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apache Software Foundation–Apache Linkis Basic management services
  In Apache Linkis <= 1.5.0, Arbitrary file deletion in Basic management services on A user with an administrator account could delete any file accessible by the Linkis system user . Users are recommended to upgrade to version 1.6.0, which fixes this issue. 2024-08-02 not yet calculated CVE-2024-27182
security@apache.org
  Apple–macOS
  A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sonoma 14.4. An app may be able to access user-sensitive data. 2024-07-29 not yet calculated CVE-2024-27809
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A race condition was addressed with improved locking. This issue is fixed in macOS Sonoma 14.5, iOS 16.7.8 and iPadOS 16.7.8, macOS Ventura 13.6.7, watchOS 10.5, visionOS 1.3, tvOS 17.5, iOS 17.5 and iPadOS 17.5, macOS Monterey 12.7.5. An attacker in a privileged network position may be able to spoof network packets. 2024-07-29 not yet calculated CVE-2024-27823
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  This issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.4. A maliciously crafted ZIP archive may bypass Gatekeeper checks. 2024-07-29 not yet calculated CVE-2024-27853
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  An information disclosure issue was addressed with improved private data redaction for log entries. This issue is fixed in iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. A local attacker may be able to determine kernel memory layout. 2024-07-29 not yet calculated CVE-2024-27863
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A path handling issue was addressed with improved validation. This issue is fixed in macOS Sonoma 14.6, iOS 17.6 and iPadOS 17.6. An app may be able to access protected user data. 2024-07-29 not yet calculated CVE-2024-27871
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  This issue was addressed with improved validation of symlinks. This issue is fixed in macOS Sonoma 14.6. An app may be able to access protected user data. 2024-07-29 not yet calculated CVE-2024-27872
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  An out-of-bounds write issue was addressed with improved input validation. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, macOS Sonoma 14.6. Processing a maliciously crafted video file may lead to unexpected app termination. 2024-07-29 not yet calculated CVE-2024-27873
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  The issue was addressed with improved memory handling. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. Processing a maliciously crafted file may lead to a denial-of-service or potentially disclose memory contents. 2024-07-29 not yet calculated CVE-2024-27877
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to access information about a user’s contacts. 2024-07-29 not yet calculated CVE-2024-27881
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to modify protected parts of the file system. 2024-07-29 not yet calculated CVE-2024-27882
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to modify protected parts of the file system. 2024-07-29 not yet calculated CVE-2024-27883
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed with a new entitlement. This issue is fixed in macOS Sonoma 14.5, watchOS 10.5, visionOS 1.2, tvOS 17.5, iOS 17.5 and iPadOS 17.5. An app may be able to access user-sensitive data. 2024-07-29 not yet calculated CVE-2024-27884
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A path handling issue was addressed with improved validation. This issue is fixed in macOS Sonoma 14.4. An app may be able to access user-sensitive data. 2024-07-29 not yet calculated CVE-2024-27887
product-security@apple.com
product-security@apple.com
  n/a–n/a
  SQL injection vulnerability in BM SOFT BMPlanning 1.0.0.1 allows authenticated users to execute arbitrary SQL commands via the SEC_IDF, LIE_IDF, PLANF_IDF, CLI_IDF, DOS_IDF, and possibly other parameters to /BMServerR.dll/BMRest. 2024-08-02 not yet calculated CVE-2024-28298
cve@mitre.org
cve@mitre.org
  Unknown–WooCommerce Customers Manager
  The WooCommerce Customers Manager WordPress plugin before 30.1 does not have CSRF checks in some places, which could allow attackers to make logged in admin users delete users via CSRF attacks 2024-08-01 not yet calculated CVE-2024-2843
contact@wpscan.com
  Python Software Foundation–CPython
  There is a MEDIUM severity vulnerability affecting CPython. The “socket” module provides a pure-Python fallback to the socket.socketpair() function for platforms that don’t support AF_UNIX, such as Windows. This pure-Python implementation uses AF_INET or AF_INET6 to create a local connected pair of sockets. The connection between the two sockets was not verified before passing the two sockets back to the user, which leaves the server socket vulnerable to a connection race from a malicious local peer. Platforms that support AF_UNIX such as Linux and macOS are not affected by this vulnerability. Versions prior to CPython 3.5 are not affected due to the vulnerable API not being included. 2024-07-29 not yet calculated CVE-2024-3219
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
cna@python.org
  Samsung Open Source–Escargot
  Heap-based Buffer Overflow vulnerability in Samsung Open Source Escargot JavaScript engine allows Overflow Buffers.This issue affects Escargot: 4.0.0. 2024-07-29 not yet calculated CVE-2024-32671
PSIRT@samsung.com
  Johnson Controls–exacqVision
  Under certain circumstances the communication between exacqVision Client and exacqVision Server will use insufficient key length and exchange 2024-08-01 not yet calculated CVE-2024-32758
productsecurity@jci.com
productsecurity@jci.com
  n/a–n/a
  Insecure Permissions vulnerability in Cosy+ devices running a firmware 21.x below 21.2s10 or a firmware 22.x below 22.1s3 are susceptible to leaking information through cookies. This is fixed in version 21.2s10 and 22.1s3 2024-08-02 not yet calculated CVE-2024-33892
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  Cosy+ devices running a firmware 21.x below 21.2s10 or a firmware 22.x below 22.1s3 are vulnerable to XSS when displaying the logs due to improper input sanitization. This is fixed in version 21.2s10 and 22.1s3. 2024-08-02 not yet calculated CVE-2024-33893
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  Insecure Permission vulnerability in Cosy+ devices running a firmware 21.x below 21.2s10 or a firmware 22.x below 22.1s3 are executing several processes with elevated privileges. 2024-08-02 not yet calculated CVE-2024-33894
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  Cosy+ devices running a firmware 21.x below 21.2s10 or a firmware 22.x below 22.1s3 use a unique key to encrypt the configuration parameters. This is fixed in version 21.2s10 and 22.1s3, the key is now unique per device. 2024-08-02 not yet calculated CVE-2024-33895
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  Cosy+ devices running a firmware 21.x below 21.2s10 or a firmware 22.x below 22.1s3 are vulnerable to code injection due to improper parameter blacklisting. This is fixed in version 21.2s10 and 22.1s3. 2024-08-02 not yet calculated CVE-2024-33896
cve@mitre.org
cve@mitre.org
cve@mitre.org
  Apache Software Foundation–Apache InLong TubeMQ Client
  Improper Control of Generation of Code (‘Code Injection’) vulnerability in Apache InLong. This issue affects Apache InLong: from 1.10.0 through 1.12.0, which could lead to Remote Code Execution. Users are advised to upgrade to Apache InLong’s 1.13.0 or cherry-pick [1] to solve it. [1]  https://github.com/apache/inlong/pull/10251 2024-08-02 not yet calculated CVE-2024-36268
security@apache.org
  Ivanti–EPM
  An unspecified SQL Injection vulnerability in Core server of Ivanti EPM 2024 flat allows an authenticated attacker within the same network to execute arbitrary code. 2024-07-29 not yet calculated CVE-2024-37381
support@hackerone.com
  n/a–n/a
  Cross Site Scripting vulnerability in Lost and Found Information System 1.0 allows a remote attacker to escalate privileges via the first, last, middle name fields in the User Profile page. 2024-07-29 not yet calculated CVE-2024-37856
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a local attacker to perform an Authentication Bypass attack due to improperly implemented security checks for standard authentication mechanisms 2024-08-02 not yet calculated CVE-2024-38884
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform a Traffic Injection attack due to improper verification of the source of a communication channel. 2024-08-02 not yet calculated CVE-2024-38886
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to expand control over the operating system from the database due to the execution of commands with unnecessary privileges. 2024-08-02 not yet calculated CVE-2024-38887
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform SQL Injection due to improper neutralization of special elements used in an SQL command. 2024-08-02 not yet calculated CVE-2024-38889
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform a Sniffing Network Traffic attack due to the cleartext transmission of sensitive information. 2024-08-02 not yet calculated CVE-2024-38891
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  ais-ltd strategyen v0.4.0 was discovered to contain a prototype pollution via the function mergeObjects. This vulnerability allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via injecting arbitrary properties. 2024-07-30 not yet calculated CVE-2024-39012
cve@mitre.org
  Unknown–SportsPress
  The SportsPress WordPress plugin before 2.7.22 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup) 2024-07-30 not yet calculated CVE-2024-3986
contact@wpscan.com
  n/a–n/a
  GraphQL Java (aka graphql-java) before 21.5 does not properly consider ExecutableNormalizedFields (ENFs) as part of preventing denial of service via introspection queries. 20.9 and 19.11 are also fixed versions. 2024-07-30 not yet calculated CVE-2024-40094
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An issue in beego v.2.2.0 and before allows a remote attacker to escalate privileges via the sendMail function located in beego/core/logs/smtp.go file 2024-07-31 not yet calculated CVE-2024-40464
cve@mitre.org
  Apple–iOS and iPadOS
  A downgrade issue was addressed with additional code-signing restrictions. This issue is fixed in macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, macOS Sonoma 14.6. An app may be able to bypass Privacy preferences. 2024-07-29 not yet calculated CVE-2024-40774
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A downgrade issue was addressed with additional code-signing restrictions. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to leak sensitive user information. 2024-07-29 not yet calculated CVE-2024-40775
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–Safari
  A use-after-free issue was addressed with improved memory management. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash. 2024-07-29 not yet calculated CVE-2024-40776
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  An authentication issue was addressed with improved state management. This issue is fixed in macOS Sonoma 14.6, iOS 17.6 and iPadOS 17.6, iOS 16.7.9 and iPadOS 16.7.9. Photos in the Hidden Photos Album may be viewed without authentication. 2024-07-29 not yet calculated CVE-2024-40778
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–Safari
  An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash. 2024-07-29 not yet calculated CVE-2024-40779
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–Safari
  An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash. 2024-07-29 not yet calculated CVE-2024-40780
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–Safari
  This issue was addressed with improved checks. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to a cross site scripting attack. 2024-07-29 not yet calculated CVE-2024-40785
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed through improved state management. This issue is fixed in iOS 17.6 and iPadOS 17.6, iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8. An attacker may be able to view sensitive user information. 2024-07-29 not yet calculated CVE-2024-40786
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed by adding an additional prompt for user consent. This issue is fixed in macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, macOS Sonoma 14.6. A shortcut may be able to bypass Internet permission requirements. 2024-07-29 not yet calculated CVE-2024-40787
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A type confusion issue was addressed with improved memory handling. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. A local attacker may be able to cause unexpected system shutdown. 2024-07-29 not yet calculated CVE-2024-40788
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–Safari
  An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash. 2024-07-29 not yet calculated CVE-2024-40789
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed by removing the vulnerable code. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, macOS Sonoma 14.6. An app may be able to access user-sensitive data. 2024-07-29 not yet calculated CVE-2024-40793
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–Safari
  This issue was addressed through improved state management. This issue is fixed in macOS Sonoma 14.6, iOS 17.6 and iPadOS 17.6, Safari 17.6. Private Browsing tabs may be accessed without authentication. 2024-07-29 not yet calculated CVE-2024-40794
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed with improved data protection. This issue is fixed in watchOS 10.6, macOS Sonoma 14.6, iOS 17.6 and iPadOS 17.6, tvOS 17.6. An app may be able to read sensitive location information. 2024-07-29 not yet calculated CVE-2024-40795
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sonoma 14.6, iOS 16.7.9 and iPadOS 16.7.9, macOS Monterey 12.7.6, macOS Ventura 13.6.8. Private browsing may leak some browsing history. 2024-07-29 not yet calculated CVE-2024-40796
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed with improved redaction of sensitive information. This issue is fixed in macOS Sonoma 14.6, iOS 16.7.9 and iPadOS 16.7.9, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to read Safari’s browsing history. 2024-07-29 not yet calculated CVE-2024-40798
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  An out-of-bounds read issue was addressed with improved input validation. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing a maliciously crafted file may lead to unexpected app termination. 2024-07-29 not yet calculated CVE-2024-40799
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A type confusion issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An attacker may be able to cause unexpected app termination. 2024-07-29 not yet calculated CVE-2024-40803
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.6. A malicious application may be able to access private information. 2024-07-29 not yet calculated CVE-2024-40804
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  An out-of-bounds read issue was addressed with improved input validation. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing a maliciously crafted file may lead to unexpected app termination. 2024-07-29 not yet calculated CVE-2024-40806
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  A logic issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. A shortcut may be able to use sensitive data with certain actions without prompting the user. 2024-07-29 not yet calculated CVE-2024-40807
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A logic issue was addressed with improved checks. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, visionOS 1.3, macOS Sonoma 14.6. A shortcut may be able to bypass Internet permission requirements. 2024-07-29 not yet calculated CVE-2024-40809
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A logic issue was addressed with improved checks. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, visionOS 1.3, macOS Sonoma 14.6. A shortcut may be able to bypass Internet permission requirements. 2024-07-29 not yet calculated CVE-2024-40812
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A lock screen issue was addressed with improved state management. This issue is fixed in watchOS 10.6, iOS 17.6 and iPadOS 17.6. An attacker with physical access may be able to use Siri to access sensitive user data. 2024-07-29 not yet calculated CVE-2024-40813
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A race condition was addressed with additional validation. This issue is fixed in macOS Ventura 13.6.8, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, macOS Sonoma 14.6. A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication. 2024-07-29 not yet calculated CVE-2024-40815
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  An out-of-bounds read was addressed with improved input validation. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. A local attacker may be able to cause unexpected system shutdown. 2024-07-29 not yet calculated CVE-2024-40816
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–Safari
  The issue was addressed with improved UI handling. This issue is fixed in macOS Sonoma 14.6, Safari 17.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. Visiting a website that frames malicious content may lead to UI spoofing. 2024-07-29 not yet calculated CVE-2024-40817
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed by restricting options offered on a locked device. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, iOS 17.6 and iPadOS 17.6, watchOS 10.6, macOS Sonoma 14.6. An attacker with physical access may be able to use Siri to access sensitive user data. 2024-07-29 not yet calculated CVE-2024-40818
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  This issue was addressed by restricting options offered on a locked device. This issue is fixed in watchOS 10.6, macOS Sonoma 14.6, iOS 17.6 and iPadOS 17.6, iOS 16.7.9 and iPadOS 16.7.9. An attacker with physical access to a device may be able to access contacts from the lock screen. 2024-07-29 not yet calculated CVE-2024-40822
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to access user-sensitive data. 2024-07-29 not yet calculated CVE-2024-40823
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to overwrite arbitrary files. 2024-07-29 not yet calculated CVE-2024-40827
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.6. An app may be able to view a contact’s phone number in system logs. 2024-07-29 not yet calculated CVE-2024-40832
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A logic issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14.6, iOS 16.7.9 and iPadOS 16.7.9, macOS Monterey 12.7.6, macOS Ventura 13.6.8. A shortcut may be able to use sensitive data with certain actions without prompting the user. 2024-07-29 not yet calculated CVE-2024-40833
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–macOS
  This issue was addressed by adding an additional prompt for user consent. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. A shortcut may be able to bypass sensitive Shortcuts app settings. 2024-07-29 not yet calculated CVE-2024-40834
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  Apple–iOS and iPadOS
  A logic issue was addressed with improved checks. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, macOS Ventura 13.6.8, macOS Monterey 12.7.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, macOS Sonoma 14.6. A shortcut may be able to use sensitive data with certain actions without prompting the user. 2024-07-29 not yet calculated CVE-2024-40835
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
product-security@apple.com
  ELECOM CO.,LTD.–WRC-X6000XS-G
  Cross-site request forgery vulnerability exists in ELECOM wireless LAN routers. Viewing a malicious page while logging in to the affected product with an administrative privilege, the user may be directed to perform unintended operations such as changing the login ID, login password, etc. 2024-08-01 not yet calculated CVE-2024-40883
vultures@jpcert.or.jp
vultures@jpcert.or.jp
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41013
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41014
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41015
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41016
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: jfs: don’t walk off the end of ealist Add a check before visiting the members of ea to make sure each ea stays within the ealist. 2024-07-29 not yet calculated CVE-2024-41017
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add a check for attr_names and oatbl Added out-of-bound checking for *ane (ATTR_NAME_ENTRY). 2024-07-29 not yet calculated CVE-2024-41018
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate ff offset This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read. 2024-07-29 not yet calculated CVE-2024-41019
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41020
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix VM_FAULT_HWPOISON handling in do_exception() There is no support for HWPOISON, MEMORY_FAILURE, or ARCH_HAS_COPY_MC on s390. Therefore we do not expect to see VM_FAULT_HWPOISON in do_exception(). However, since commit af19487f00f3 (“mm: make PTE_MARKER_SWAPIN_ERROR more general”), it is possible to see VM_FAULT_HWPOISON in combination with PTE_MARKER_POISONED, even on architectures that do not support HWPOISON otherwise. In this case, we will end up on the BUG() in do_exception(). Fix this by treating VM_FAULT_HWPOISON the same as VM_FAULT_SIGBUS, similar to x86 when MEMORY_FAILURE is not configured. Also print unexpected fault flags, for easier debugging. Note that VM_FAULT_HWPOISON_LARGE is not expected, because s390 cannot support swap entries on other levels than PTE level. 2024-07-29 not yet calculated CVE-2024-41021
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq() The “instance” variable needs to be signed for the error handling to work. 2024-07-29 not yet calculated CVE-2024-41022
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Fix task_struct reference leak During the execution of the following stress test with linux-rt: stress-ng –cyclic 30 –timeout 30 –minimize –quiet kmemleak frequently reported a memory leak concerning the task_struct: unreferenced object 0xffff8881305b8000 (size 16136): comm “stress-ng”, pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 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 ……………. debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S…………… backtrace: [<00000000046b6790>] dup_task_struct+0x30/0x540 [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0 [<00000000ced59777>] kernel_clone+0xb0/0x770 [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0 [<000000001dbf2008>] do_syscall_64+0x5d/0xf0 [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 The issue occurs in start_dl_timer(), which increments the task_struct reference count and sets a timer. The timer callback, dl_task_timer, is supposed to decrement the reference count upon expiration. However, if enqueue_task_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak. This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled. 2024-07-29 not yet calculated CVE-2024-41023
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Restrict untrusted app to attach to privileged PD Untrusted application with access to only non-secure fastrpc device node can attach to root_pd or static PDs if it can make the respective init request. This can cause problems as the untrusted application can send bad requests to root_pd or static PDs. Add changes to reject attach to privileged PDs if the request is being made using non-secure fastrpc device node. 2024-07-29 not yet calculated CVE-2024-41024
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix memory leak in audio daemon attach operation Audio PD daemon send the name as part of the init IOCTL call. This name needs to be copied to kernel for which memory is allocated. This memory is never freed which might result in memory leak. Free the memory when it is not needed. 2024-07-29 not yet calculated CVE-2024-41025
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: mmc: davinci_mmc: Prevent transmitted data size from exceeding sgm’s length No check is done on the size of the data to be transmiited. This causes a kernel panic when this size exceeds the sg_miter’s length. Limit the number of transmitted bytes to sgm->length. 2024-07-29 not yet calculated CVE-2024-41026
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: Fix userfaultfd_api to return EINVAL as expected Currently if we request a feature that is not set in the Kernel config we fail silently and return all the available features. However, the man page indicates we should return an EINVAL. We need to fix this issue since we can end up with a Kernel warning should a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with the config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660 2024-07-29 not yet calculated CVE-2024-41027
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: platform/x86: toshiba_acpi: Fix array out-of-bounds access In order to use toshiba_dmi_quirks[] together with the standard DMI matching functions, it must be terminated by a empty entry. Since this entry is missing, an array out-of-bounds access occurs every time the quirk list is processed. Fix this by adding the terminating empty entry. 2024-07-29 not yet calculated CVE-2024-41028
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: nvmem: core: limit cell sysfs permissions to main attribute ones The cell sysfs attribute should not provide more access to the nvmem data than the main attribute itself. For example if nvme_config::root_only was set, the cell attribute would still provide read access to everybody. Mask out permissions not available on the main attribute. 2024-07-29 not yet calculated CVE-2024-41029
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ksmbd: discard write access to the directory open may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let’s discard the write access when opening a directory. list_add corruption. next is NULL. ————[ cut here ]———— kernel BUG at lib/list_debug.c:26! pc : __list_add_valid+0x88/0xbc lr : __list_add_valid+0x88/0xbc Call trace: __list_add_valid+0x88/0xbc fuse_finish_open+0x11c/0x170 fuse_open_common+0x284/0x5e8 fuse_dir_open+0x14/0x24 do_dentry_open+0x2a4/0x4e0 dentry_open+0x50/0x80 smb2_open+0xbe4/0x15a4 handle_ksmbd_work+0x478/0x5ec process_one_work+0x1b4/0x448 worker_thread+0x25c/0x430 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20 2024-07-29 not yet calculated CVE-2024-41030
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: mm/filemap: skip to create PMD-sized page cache if needed On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB. The PMD-sized page cache can’t be supported by xarray as the following error messages indicate. ————[ cut here ]———— WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 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_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net net_failover virtio_console virtio_blk failover dimlib virtio_mmio CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=–) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff800087a4f6c0 x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858 x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000 x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28 x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8 x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x720 truncate_inode_partial_folio+0xdc/0x160 truncate_inode_pages_range+0x1b4/0x4a8 truncate_pagecache_range+0x84/0xa0 xfs_flush_unmap_range+0x70/0x90 [xfs] xfs_file_fallocate+0xfc/0x4d8 [xfs] vfs_fallocate+0x124/0x2e8 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by skipping to allocate PMD-sized page cache when its size is larger than MAX_PAGECACHE_ORDER. For this specific case, we will fall to regular path where the readahead window is determined by BDI’s sysfs file (read_ahead_kb). 2024-07-29 not yet calculated CVE-2024-41031
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: check if a hash-index is in cpu_possible_mask The problem is that there are systems where cpu_possible_mask has gaps between set CPUs, for example SPARC. In this scenario addr_to_vb_xa() hash function can return an index which accesses to not-possible and not setup CPU area using per_cpu() macro. This results in an oops on SPARC. A per-cpu vmap_block_queue is also used as hash table, incorrectly assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index to a next possible CPU. 2024-07-29 not yet calculated CVE-2024-41032
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cachestat: do not flush stats in recency check syzbot detects that cachestat() is flushing stats, which can sleep, in its RCU read section (see [1]). This is done in the workingset_test_recent() step (which checks if the folio’s eviction is recent). Move the stat flushing step to before the RCU read section of cachestat, and skip stat flushing during the recency check. [1]: https://lore.kernel.org/cgroups/000000000000f71227061bdf97e0@google.com/ 2024-07-29 not yet calculated CVE-2024-41033
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug on rename operation of broken directory Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size. This is because nilfs_dotdot(), which gets parent directory reference entry (“..”) of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories. Fix this issue by checking required directory entries (“.” and “..”) in the first chunk of the directory in nilfs_dotdot(). 2024-07-29 not yet calculated CVE-2024-41034
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41035
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Fix deadlock with the SPI chip variant When SMP is enabled and spinlocks are actually functional then there is a deadlock with the ‘statelock’ spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup – CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock. 2024-07-29 not yet calculated CVE-2024-41036
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: fix null deref on system suspend entry When system enters suspend with an active stream, SOF core calls hw_params_upon_resume(). On Intel platforms with HDA DMA used to manage the link DMA, this leads to call chain of hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() -> hda_ipc4_post_trigger() A bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first, which clears hext_stream->link_substream, and then hda_ipc4_post_trigger() is called with a NULL snd_pcm_substream pointer. 2024-07-29 not yet calculated CVE-2024-41037
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers Check that all fields of a V2 algorithm header fit into the available firmware data buffer. The wmfw V2 format introduced variable-length strings in the algorithm block header. This means the overall header length is variable, and the position of most fields varies depending on the length of the string fields. Each field must be checked to ensure that it does not overflow the firmware data buffer. As this ia bugfix patch, the fixes avoid making any significant change to the existing code. This makes it easier to review and less likely to introduce new bugs. 2024-07-29 not yet calculated CVE-2024-41038
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix overflow checking of wmfw header Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn’t guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used. 2024-07-29 not yet calculated CVE-2024-41039
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix UAF when resolving a clash KASAN reports the following UAF: BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] Read of size 1 at addr ffff888c07603600 by task handler130/6469 Call Trace: <IRQ> dump_stack_lvl+0x48/0x70 print_address_description.constprop.0+0x33/0x3d0 print_report+0xc0/0x2b0 kasan_report+0xd0/0x120 __asan_load1+0x6c/0x80 tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] tcf_ct_act+0x886/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 __irq_exit_rcu+0x82/0xc0 irq_exit_rcu+0xe/0x20 common_interrupt+0xa1/0xb0 </IRQ> <TASK> asm_common_interrupt+0x27/0x40 Allocated by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_alloc_info+0x1e/0x40 __kasan_krealloc+0x133/0x190 krealloc+0xaa/0x130 nf_ct_ext_add+0xed/0x230 [nf_conntrack] tcf_ct_act+0x1095/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 Freed by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_free_info+0x2b/0x60 ____kasan_slab_free+0x180/0x1f0 __kasan_slab_free+0x12/0x30 slab_free_freelist_hook+0xd2/0x1a0 __kmem_cache_free+0x1a2/0x2f0 kfree+0x78/0x120 nf_conntrack_free+0x74/0x130 [nf_conntrack] nf_ct_destroy+0xb2/0x140 [nf_conntrack] __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack] nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack] __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack] tcf_ct_act+0x12ad/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 The ct may be dropped if a clash has been resolved but is still passed to the tcf_ct_flow_table_process_conn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack. 2024-07-29 not yet calculated CVE-2024-41040
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port(). syzkaller triggered the warning [0] in udp_v4_early_demux(). In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount of the looked-up sk and use sock_pfree() as skb->destructor, so we check SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace period. Currently, SOCK_RCU_FREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCK_RCU_FREE check is done too early in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race window: CPU1 CPU2 —- —- udp_v4_early_demux() udp_lib_get_port() | |- hlist_add_head_rcu() |- sk = __udp4_lib_demux_lookup() | |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk)); `- sock_set_flag(sk, SOCK_RCU_FREE) We had the same bug in TCP and fixed it in commit 871019b22d1b (“net: set SOCK_RCU_FREE before inserting socket into hashtable”). Let’s apply the same fix for UDP. [0]: WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599 Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349 ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624 __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738 netif_receive_skb_internal net/core/dev.c:5824 [inline] netif_receive_skb+0x271/0x300 net/core/dev.c:5884 tun_rx_batched drivers/net/tun.c:1549 [inline] tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002 tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x76f/0x8d0 fs/read_write.c:590 ksys_write+0xbf/0x190 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+0x41/0x50 fs/read_write.c:652 x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 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 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R —truncated— 2024-07-29 not yet calculated CVE-2024-41041
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prefer nft_chain_validate nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE). It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again. nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s. This also fixes a crash bug. Old loop detection code can result in unbounded recursion: BUG: TASK stack guard page was hit at …. Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..] with a suitable ruleset during validation of register stores. I can’t see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don’t have a full picture of the rule graph. For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace). 2024-07-29 not yet calculated CVE-2024-41042
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: drop bogus WARN_ON Happens when rules get flushed/deleted while packet is out, so remove this WARN_ON. This WARN exists in one form or another since v4.14, no need to backport this to older releases, hence use a more recent fixes tag. 2024-07-29 not yet calculated CVE-2024-41043
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41044
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: Defer work in bpf_timer_cancel_and_free Currently, the same case as previous patch (two timer callbacks trying to cancel each other) can be invoked through bpf_map_update_elem as well, or more precisely, freeing map elements containing timers. Since this relies on hrtimer_cancel as well, it is prone to the same deadlock situation as the previous patch. It would be sufficient to use hrtimer_try_to_cancel to fix this problem, as the timer cannot be enqueued after async_cancel_and_free. Once async_cancel_and_free has been done, the timer must be reinitialized before it can be armed again. The callback running in parallel trying to arm the timer will fail, and freeing bpf_hrtimer without waiting is sufficient (given kfree_rcu), and bpf_timer_cb will return HRTIMER_NORESTART, preventing the timer from being rearmed again. However, there exists a UAF scenario where the callback arms the timer before entering this function, such that if cancellation fails (due to timer callback invoking this routine, or the target timer callback running concurrently). In such a case, if the timer expiration is significantly far in the future, the RCU grace period expiration happening before it will free the bpf_hrtimer state and along with it the struct hrtimer, that is enqueued. Hence, it is clear cancellation needs to occur after async_cancel_and_free, and yet it cannot be done inline due to deadlock issues. We thus modify bpf_timer_cancel_and_free to defer work to the global workqueue, adding a work_struct alongside rcu_head (both used at _different_ points of time, so can share space). Update existing code comments to reflect the new state of affairs. 2024-07-29 not yet calculated CVE-2024-41045
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. 2024-07-29 not yet calculated CVE-2024-41046
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: i40e: Fix XDP program unloading while removing the driver The commit 6533e558c650 (“i40e: Fix reset path while removing the driver”) introduced a new PF state “__I40E_IN_REMOVE” to block modifying the XDP program while the driver is being removed. Unfortunately, such a change is useful only if the “.ndo_bpf()” callback was called out of the rmmod context because unloading the existing XDP program is also a part of driver removing procedure. In other words, from the rmmod context the driver is expected to unload the XDP program without reporting any errors. Otherwise, the kernel warning with callstack is printed out to dmesg. Example failing scenario: 1. Load the i40e driver. 2. Load the XDP program. 3. Unload the i40e driver (using “rmmod” command). The example kernel warning log: [ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870 […] [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870 […] [ +0.002726] Call Trace: [ +0.002457] <TASK> [ +0.002119] ? __warn+0x80/0x120 [ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870 [ +0.005586] ? report_bug+0x164/0x190 [ +0.003678] ? handle_bug+0x3c/0x80 [ +0.003503] ? exc_invalid_op+0x17/0x70 [ +0.003846] ? asm_exc_invalid_op+0x1a/0x20 [ +0.004200] ? unregister_netdevice_many_notify+0x7a9/0x870 [ +0.005579] ? unregister_netdevice_many_notify+0x3cc/0x870 [ +0.005586] unregister_netdevice_queue+0xf7/0x140 [ +0.004806] unregister_netdev+0x1c/0x30 [ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e] [ +0.004604] i40e_remove+0x1a1/0x420 [i40e] [ +0.004220] pci_device_remove+0x3f/0xb0 [ +0.003943] device_release_driver_internal+0x19f/0x200 [ +0.005243] driver_detach+0x48/0x90 [ +0.003586] bus_remove_driver+0x6d/0xf0 [ +0.003939] pci_unregister_driver+0x2e/0xb0 [ +0.004278] i40e_exit_module+0x10/0x5f0 [i40e] [ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310 [ +0.005153] do_syscall_64+0x85/0x170 [ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220 [ +0.004886] ? do_syscall_64+0x95/0x170 [ +0.003851] ? exc_page_fault+0x7e/0x180 [ +0.003932] entry_SYSCALL_64_after_hwframe+0x71/0x79 [ +0.005064] RIP: 0033:0x7f59dc9347cb [ +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 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 35 16 0c 00 f7 d8 64 89 01 48 [ +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb [ +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748 [ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000 [ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000 [ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000 [ +0.007151] </TASK> [ +0.002204] —[ end trace 0000000000000000 ]— Fix this by checking if the XDP program is being loaded or unloaded. Then, block only loading a new program while “__I40E_IN_REMOVE” is set. Also, move testing “__I40E_IN_REMOVE” flag to the beginning of XDP_SETUP callback to avoid unnecessary operations and checks. 2024-07-29 not yet calculated CVE-2024-41047
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41048
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: filelock: fix potential use-after-free in posix_lock_inode Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode’s list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn’t happen. 2024-07-29 not yet calculated CVE-2024-41049
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cachefiles: cyclic allocation of msg_id to avoid reuse Reusing the msg_id after a maliciously completed reopen request may cause a read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3 ————————————————- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done) cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // will not set the object to close // because ondemand_id && fd is valid. // ondemand_object_worker() is done // but the object is still reopening. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reuse msg_id 6 process_open_req copen 6,A.size // The expected failed copen was executed successfully Expect copen to fail, and when it does, it closes fd, which sets the object to close, and then close triggers reopen again. However, due to msg_id reuse resulting in a successful copen, the anonymous fd is not closed until the daemon exits. Therefore read requests waiting for reopen to complete may trigger hung task. To avoid this issue, allocate the msg_id cyclically to avoid reusing the msg_id for a very short duration of time. 2024-07-29 not yet calculated CVE-2024-41050
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cachefiles: wait for ondemand_object_worker to finish when dropping object When queuing ondemand_object_worker() to re-open the object, cachefiles_object is not pinned. The cachefiles_object may be freed when the pending read request is completed intentionally and the related erofs is umounted. If ondemand_object_worker() runs after the object is freed, it will incur use-after-free problem as shown below. process A processs B process C process D cachefiles_ondemand_send_req() // send a read req X // wait for its completion // close ondemand fd cachefiles_ondemand_fd_release() // set object as CLOSE cachefiles_ondemand_daemon_read() // set object as REOPENING queue_work(fscache_wq, &info->ondemand_work) // close /dev/cachefiles cachefiles_daemon_release cachefiles_flush_reqs complete(&req->done) // read req X is completed // umount the erofs fs cachefiles_put_object() // object will be freed cachefiles_ondemand_deinit_obj_info() kmem_cache_free(object) // both info and object are freed ondemand_object_worker() When dropping an object, it is no longer necessary to reopen the object, so use cancel_work_sync() to cancel or wait for ondemand_object_worker() to finish. 2024-07-29 not yet calculated CVE-2024-41051
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Init the count variable in collecting hot-reset devices The count variable is used without initialization, it results in mistakes in the device counting and crashes the userspace if the get hot reset info path is triggered. 2024-07-29 not yet calculated CVE-2024-41052
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix ufshcd_abort_one racing issue When ufshcd_abort_one is racing with the completion ISR, the completed tag of the request’s mq_hctx pointer will be set to NULL by ISR. Return success when request is completed by ISR because ufshcd_abort_one does not need to do anything. The racing flow is: Thread A ufshcd_err_handler step 1 … ufshcd_abort_one ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) step 3 ufshcd_mcq_req_to_hwq blk_mq_unique_tag rq->mq_hctx->queue_num step 5 Thread B ufs_mtk_mcq_intr(cq complete ISR) step 2 scsi_done … __blk_mq_free_request rq->mq_hctx = NULL; step 4 Below is KE back trace. ufshcd_try_to_abort_task: cmd at tag 41 not pending in the device. ufshcd_try_to_abort_task: cmd at tag=41 is cleared. Aborting tag 41 / CDB 0x28 succeeded Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194 pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14 lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise] do_mem_abort+0x58/0x118 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x54/0x90 el1h_64_sync+0x68/0x6c blk_mq_unique_tag+0x8/0x14 ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise] process_one_work+0x208/0x4fc worker_thread+0x228/0x438 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20 2024-07-29 not yet calculated CVE-2024-41053
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix ufshcd_clear_cmd racing issue When ufshcd_clear_cmd is racing with the completion ISR, the completed tag of the request’s mq_hctx pointer will be set to NULL by the ISR. And ufshcd_clear_cmd’s call to ufshcd_mcq_req_to_hwq will get NULL pointer KE. Return success when the request is completed by ISR because sq does not need cleanup. The racing flow is: Thread A ufshcd_err_handler step 1 ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) step 3 ufshcd_clear_cmd … ufshcd_mcq_req_to_hwq blk_mq_unique_tag rq->mq_hctx->queue_num step 5 Thread B ufs_mtk_mcq_intr(cq complete ISR) step 2 scsi_done … __blk_mq_free_request rq->mq_hctx = NULL; step 4 Below is KE back trace: ufshcd_try_to_abort_task: cmd pending in the device. tag = 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194 pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14 lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise] Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise] Call trace: dump_backtrace+0xf8/0x148 show_stack+0x18/0x24 dump_stack_lvl+0x60/0x7c dump_stack+0x18/0x3c mrdump_common_die+0x24c/0x398 [mrdump] ipanic_die+0x20/0x34 [mrdump] notify_die+0x80/0xd8 die+0x94/0x2b8 __do_kernel_fault+0x264/0x298 do_page_fault+0xa4/0x4b8 do_translation_fault+0x38/0x54 do_mem_abort+0x58/0x118 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x54/0x90 el1h_64_sync+0x68/0x6c blk_mq_unique_tag+0x8/0x14 ufshcd_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise] ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise] ufshcd_err_handler+0xa7c/0xfa8 [ufs_mediatek_mod_ise] process_one_work+0x208/0x4fc worker_thread+0x228/0x438 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20 2024-07-29 not yet calculated CVE-2024-41054
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 (“mm/sparsemem: fix race in accessing memory_section->usage”) changed pfn_section_valid() to add a READ_ONCE() call around “ms->usage” to fix a race with section_deactivate() where ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it. 2024-07-29 not yet calculated CVE-2024-41055
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files. In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing. 2024-07-29 not yet calculated CVE-2024-41056
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600 Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109 CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566 Call Trace: <TASK> kasan_report+0x93/0xc0 cachefiles_withdraw_cookie+0x4d9/0x600 fscache_cookie_state_machine+0x5c8/0x1230 fscache_cookie_worker+0x91/0x1c0 process_one_work+0x7fa/0x1800 […] Allocated by task 117: kmalloc_trace+0x1b3/0x3c0 cachefiles_acquire_volume+0xf3/0x9c0 fscache_create_volume_work+0x97/0x150 process_one_work+0x7fa/0x1800 […] Freed by task 120301: kfree+0xf1/0x2c0 cachefiles_withdraw_cache+0x3fa/0x920 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 do_exit+0x87a/0x29b0 […] ================================================================== Following is the process that triggers the issue: p1 | p2 ———————————————————— fscache_begin_lookup fscache_begin_volume_access fscache_cache_is_live(fscache_cache) cachefiles_daemon_release cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache fscache_withdraw_cache fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN); cachefiles_withdraw_objects(cache) fscache_wait_for_objects(fscache) atomic_read(&fscache_cache->object_count) == 0 fscache_perform_lookup cachefiles_lookup_cookie cachefiles_alloc_object refcount_set(&object->ref, 1); object->volume = volume fscache_count_object(vcookie->cache); atomic_inc(&fscache_cache->object_count) cachefiles_withdraw_volumes cachefiles_withdraw_volume fscache_withdraw_volume __cachefiles_free_volume kfree(cachefiles_volume) fscache_cookie_state_machine cachefiles_withdraw_cookie cache = object->volume->cache; // cachefiles_volume UAF !!! After setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups to complete first, and then wait for fscache_cache->object_count == 0 to avoid the cookie exiting after the volume has been freed and triggering the above issue. Therefore call fscache_withdraw_volume() before calling cachefiles_withdraw_objects(). This way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two cases will occur: 1) fscache_begin_lookup fails in fscache_begin_volume_access(). 2) fscache_withdraw_volume() will ensure that fscache_count_object() has been executed before calling fscache_wait_for_objects(). 2024-07-29 not yet calculated CVE-2024-41057
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in fscache_withdraw_volume() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370 Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798 CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565 Call Trace: kasan_check_range+0xf6/0x1b0 fscache_withdraw_volume+0x2e1/0x370 cachefiles_withdraw_volume+0x31/0x50 cachefiles_withdraw_cache+0x3ad/0x900 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 Allocated by task 5820: __kmalloc+0x1df/0x4b0 fscache_alloc_volume+0x70/0x600 __fscache_acquire_volume+0x1c/0x610 erofs_fscache_register_volume+0x96/0x1a0 erofs_fscache_register_fs+0x49a/0x690 erofs_fc_fill_super+0x6c0/0xcc0 vfs_get_super+0xa9/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 […] Freed by task 5820: kfree+0xf1/0x2c0 fscache_put_volume.part.0+0x5cb/0x9e0 erofs_fscache_unregister_fs+0x157/0x1b0 erofs_kill_sb+0xd9/0x1c0 deactivate_locked_super+0xa3/0x100 vfs_get_super+0x105/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 […] ================================================================== Following is the process that triggers the issue: mount failed | daemon exit ———————————————————— deactivate_locked_super cachefiles_daemon_release erofs_kill_sb erofs_fscache_unregister_fs fscache_relinquish_volume __fscache_relinquish_volume fscache_put_volume(fscache_volume, fscache_volume_put_relinquish) zero = __refcount_dec_and_test(&fscache_volume->ref, &ref); cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache cachefiles_withdraw_volumes list_del_init(&volume->cache_link) fscache_free_volume(fscache_volume) cache->ops->free_volume cachefiles_free_volume list_del_init(&cachefiles_volume->cache_link); kfree(fscache_volume) cachefiles_withdraw_volume fscache_withdraw_volume fscache_volume->n_accesses // fscache_volume UAF !!! The fscache_volume in cache->volumes must not have been freed yet, but its reference count may be 0. So use the new fscache_try_get_volume() helper function try to get its reference count. If the reference count of fscache_volume is 0, fscache_put_volume() is freeing it, so wait for it to be removed from cache->volumes. If its reference count is not 0, call cachefiles_withdraw_volume() with reference count protection to avoid the above issue. 2024-07-29 not yet calculated CVE-2024-41058
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41059
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41060
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport [Why] Potential out of bounds access in dml2_calculate_rq_and_dlg_params() because the value of out_lowest_state_idx used as an index for FCLKChangeSupport array can be greater than 1. [How] Currently dml2 core specifies identical values for all FCLKChangeSupport elements. Always use index 0 in the condition to avoid out of bounds access. 2024-07-29 not yet calculated CVE-2024-41061
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41062
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41063
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41064
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Whitelist dtl slub object for copying to userspace Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below. kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85 Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3) MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e CFAR: c0000000001fdc80 IRQMASK: 0 [ … GPRs omitted … ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Call Trace: usercopy_abort+0x74/0xb0 (unreliable) __check_heap_object+0xf8/0x120 check_heap_object+0x218/0x240 __check_object_size+0x84/0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec — interrupt: 3000 at 0x7fff81f3ab34 Commit 6d07d1cd300f (“usercopy: Restrict non-usercopy caches to size 0”) requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object. 2024-07-29 not yet calculated CVE-2024-41065
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41066
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: scrub: handle RST lookup error correctly [BUG] When running btrfs/060 with forced RST feature, it would crash the following ASSERT() inside scrub_read_endio(): ASSERT(sector_nr < stripe->nr_sectors); Before that, we would have tree dump from btrfs_get_raid_extent_offset(), as we failed to find the RST entry for the range. [CAUSE] Inside scrub_submit_extent_sector_read() every time we allocated a new bbio we immediately called btrfs_map_block() to make sure there was some RST range covering the scrub target. But if btrfs_map_block() fails, we immediately call endio for the bbio, while the bbio is newly allocated, it’s completely empty. Then inside scrub_read_endio(), we go through the bvecs to find the sector number (as bi_sector is no longer reliable if the bio is submitted to lower layers). And since the bio is empty, such bvecs iteration would not find any sector matching the sector, and return sector_nr == stripe->nr_sectors, triggering the ASSERT(). [FIX] Instead of calling btrfs_map_block() after allocating a new bbio, call btrfs_map_block() first. Since our only objective of calling btrfs_map_block() is only to update stripe_len, there is really no need to do that after btrfs_alloc_bio(). This new timing would avoid the problem of handling empty bbio completely, and in fact fixes a possible race window for the old code, where if the submission thread is the only owner of the pending_io, the scrub would never finish (since we didn’t decrease the pending_io counter). Although the root cause of RST lookup failure still needs to be addressed. 2024-07-29 not yet calculated CVE-2024-41067
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41068
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to freed memory Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed. 2024-07-29 not yet calculated CVE-2024-41069
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41070
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Avoid address calculations via out of bounds array indexing req->n_channels must be set before req->channels[] can be used. This patch fixes one of the issues encountered in [1]. [ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4 [ 83.964258] index 0 is out of range for type ‘struct ieee80211_channel *[]’ […] [ 83.964264] Call Trace: [ 83.964267] <TASK> [ 83.964269] dump_stack_lvl+0x3f/0xc0 [ 83.964274] __ubsan_handle_out_of_bounds+0xec/0x110 [ 83.964278] ieee80211_prep_hw_scan+0x2db/0x4b0 [ 83.964281] __ieee80211_start_scan+0x601/0x990 [ 83.964291] nl80211_trigger_scan+0x874/0x980 [ 83.964295] genl_family_rcv_msg_doit+0xe8/0x160 [ 83.964298] genl_rcv_msg+0x240/0x270 […] [1] https://bugzilla.kernel.org/show_bug.cgi?id=218810 2024-07-29 not yet calculated CVE-2024-41071
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41072
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41073
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cachefiles: Set object to close if ondemand_id < 0 in copen If copen is maliciously called in the user mode, it may delete the request corresponding to the random id. And the request may have not been read yet. Note that when the object is set to reopen, the open request will be done with the still reopen state in above case. As a result, the request corresponding to this object is always skipped in select_req function, so the read request is never completed and blocks other process. Fix this issue by simply set object to close if its id < 0 in copen. 2024-07-29 not yet calculated CVE-2024-41074
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cachefiles: add consistency check for copen/cread This prevents malicious processes from completing random copen/cread requests and crashing the system. Added checks are listed below: * Generic, copen can only complete open requests, and cread can only complete read requests. * For copen, ondemand_id must not be 0, because this indicates that the request has not been read by the daemon. * For cread, the object corresponding to fd and req should be the same. 2024-07-29 not yet calculated CVE-2024-41075
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix memory leak in nfs4_set_security_label We leak nfs_fattr and nfs4_label every time we set a security xattr. 2024-07-29 not yet calculated CVE-2024-41076
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: null_blk: fix validation of block size Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check. Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1]. [axboe: remove unnecessary braces and != 0 check] 2024-07-29 not yet calculated CVE-2024-41077
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41078
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41079
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee (“io_uring: drop ctx->uring_lock before acquiring sqd->lock”), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock. 2024-07-29 not yet calculated CVE-2024-41080
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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(). 2024-07-29 not yet calculated CVE-2024-41081
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41082
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_page_mkwrite() to check folio->mapping is valid Fix netfs_page_mkwrite() to check that folio->mapping is valid once it has taken the folio lock (as filemap_page_mkwrite() does). Without this, generic/247 occasionally oopses with something like the following: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) – not-present page RIP: 0010:trace_event_raw_event_netfs_folio+0x61/0xc0 … Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x6e/0xa0 ? exc_page_fault+0xc2/0xe0 ? asm_exc_page_fault+0x22/0x30 ? trace_event_raw_event_netfs_folio+0x61/0xc0 trace_netfs_folio+0x39/0x40 netfs_page_mkwrite+0x14c/0x1d0 do_page_mkwrite+0x50/0x90 do_pte_missing+0x184/0x200 __handle_mm_fault+0x42d/0x500 handle_mm_fault+0x121/0x1f0 do_user_addr_fault+0x23e/0x3c0 exc_page_fault+0xc2/0xe0 asm_exc_page_fault+0x22/0x30 This is due to the invalidate_inode_pages2_range() issued at the end of the DIO write interfering with the mmap’d writes. 2024-07-29 not yet calculated CVE-2024-41083
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cxl/region: Avoid null pointer dereference in region lookup cxl_dpa_to_region() looks up a region based on a memdev and DPA. It wrongly assumes an endpoint found mapping the DPA is also of a fully assembled region. When not true it leads to a null pointer dereference looking up the region name. This appears during testing of region lookup after a failure to assemble a BIOS defined region or if the lookup raced with the assembly of the BIOS defined region. Failure to clean up BIOS defined regions that fail assembly is an issue in itself and a fix to that problem will alleviate some of the impact. It will not alleviate the race condition so let’s harden this path. The behavior change is that the kernel oops due to a null pointer dereference is replaced with a dev_dbg() message noting that an endpoint was mapped. Additional comments are added so that future users of this function can more clearly understand what it provides. 2024-07-29 not yet calculated CVE-2024-41084
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cxl/mem: Fix no cxl_nvd during pmem region auto-assembling When CXL subsystem is auto-assembling a pmem region during cxl endpoint port probing, always hit below calltrace. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) – not-present page RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? do_user_addr_fault+0x65/0x6b0 ? exc_page_fault+0x7d/0x170 ? asm_exc_page_fault+0x26/0x30 ? cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] ? cxl_pmem_region_probe+0x1ac/0x360 [cxl_pmem] cxl_bus_probe+0x1b/0x60 [cxl_core] really_probe+0x173/0x410 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x90/0x120 bus_for_each_drv+0x84/0xe0 __device_attach+0xbc/0x1f0 bus_probe_device+0x90/0xa0 device_add+0x51c/0x710 devm_cxl_add_pmem_region+0x1b5/0x380 [cxl_core] cxl_bus_probe+0x1b/0x60 [cxl_core] The cxl_nvd of the memdev needs to be available during the pmem region probe. Currently the cxl_nvd is registered after the endpoint port probe. The endpoint probe, in the case of autoassembly of regions, can cause a pmem region probe requiring the not yet available cxl_nvd. Adjust the sequence so this dependency is met. This requires adding a port parameter to cxl_find_nvdimm_bridge() that can be used to query the ancestor root port. The endpoint port is not yet available, but will share a common ancestor with its parent, so start the query from there instead. 2024-07-29 not yet calculated CVE-2024-41085
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: bcachefs: Fix sb_field_downgrade validation – bch2_sb_downgrade_validate() wasn’t checking for a downgrade entry extending past the end of the superblock section – for_each_downgrade_entry() is used in to_text() and needs to work on malformed input; it also was missing a check for a field extending past the end of the section 2024-07-29 not yet calculated CVE-2024-41086
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41087
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: fix infinite loop when xmit fails When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). … and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. [mkl: use more imperative wording in patch description] 2024-07-29 not yet calculated CVE-2024-41088
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41089
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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 2024-07-29 not yet calculated CVE-2024-41090
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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 2024-07-29 not yet calculated CVE-2024-41091
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix potential UAF by revoke of fence registers CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence … <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) … <4>[ 609.603992] ————[ cut here ]———— <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] … <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> … <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 … In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3d587 (“drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence”), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a (“drm/i915/gt: Make fence revocation unequivocal”) replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it. The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1) 2024-07-29 not yet calculated CVE-2024-41092
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. 2024-07-29 not yet calculated CVE-2024-41093
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only set smem_start is enable per module option Only export struct fb_info.fix.smem_start if that is required by the user and the memory does not come from vmalloc(). Setting struct fb_info.fix.smem_start breaks systems where DMA memory is backed by vmalloc address space. An example error is shown below. [ 3.536043] ————[ cut here ]———— [ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000) [ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98 [ 3.565455] Modules linked in: [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250 [ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT) [ 3.582452] Workqueue: events_unbound deferred_probe_work_func [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 3.595233] pc : __virt_to_phys+0x68/0x98 [ 3.599246] lr : __virt_to_phys+0x68/0x98 [ 3.603276] sp : ffff800083603990 [ 3.677939] Call trace: [ 3.680393] __virt_to_phys+0x68/0x98 [ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238 [ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0 [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68 [ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0 [ 3.705161] drm_client_register+0x60/0xb0 [ 3.709269] drm_fbdev_dma_setup+0x94/0x148 Additionally, DMA memory is assumed to by contiguous in physical address space, which is not guaranteed by vmalloc(). Resolve this by checking the module flag drm_leak_fbdev_smem when DRM allocated the instance of struct fb_info. Fbdev-dma then only sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also guarantee that the framebuffer is not located in vmalloc address space. 2024-07-29 not yet calculated CVE-2024-41094
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41095
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: PCI/MSI: Fix UAF in msi_capability_init KFENCE reports the following UAF: BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488 Use-after-free read at 0x0000000024629571 (in kfence-#12): __pci_enable_msi_range+0x2c0/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128 allocated by task 81 on cpu 7 at 10.808142s: __kmem_cache_alloc_node+0x1f0/0x2bc kmalloc_trace+0x44/0x138 msi_alloc_desc+0x3c/0x9c msi_domain_insert_msi_desc+0x30/0x78 msi_setup_msi_desc+0x13c/0x184 __pci_enable_msi_range+0x258/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 freed by task 81 on cpu 7 at 10.811436s: msi_domain_free_descs+0xd4/0x10c msi_domain_free_locked.part.0+0xc0/0x1d8 msi_domain_alloc_irqs_all_locked+0xb4/0xbc pci_msi_setup_msi_irqs+0x30/0x4c __pci_enable_msi_range+0x2a8/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 Descriptor allocation done in: __pci_enable_msi_range msi_capability_init msi_setup_msi_desc msi_insert_msi_desc msi_domain_insert_msi_desc msi_alloc_desc … Freed in case of failure in __msi_domain_alloc_locked() __pci_enable_msi_range msi_capability_init pci_msi_setup_msi_irqs msi_domain_alloc_irqs_all_locked msi_domain_alloc_locked __msi_domain_alloc_locked => fails msi_domain_free_locked … That failure propagates back to pci_msi_setup_msi_irqs() in msi_capability_init() which accesses the descriptor for unmasking in the error exit path. Cure it by copying the descriptor and using the copy for the error exit path unmask operation. [ tglx: Massaged change log ] 2024-07-29 not yet calculated CVE-2024-41096
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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 2024-07-29 not yet calculated CVE-2024-41097
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-41098
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  EC-CUBE CO.,LTD.–EC-CUBE Web API Plugin
  Stored cross-site scripting vulnerability exists in EC-CUBE Web API Plugin. When there are multiple users using OAuth Management feature and one of them inputs some crafted value on the OAuth Management page, an arbitrary script may be executed on the web browser of the other user who accessed the management page. 2024-07-30 not yet calculated CVE-2024-41141
vultures@jpcert.or.jp
vultures@jpcert.or.jp
  Sky Co.,LTD.–SKYSEA Client View
  Origin validation error vulnerability exists in SKYSEA Client View Ver.3.013.00 to Ver.19.210.04e. If this vulnerability is exploited, an arbitrary process may be executed with SYSTEM privilege by a user who can log in to the PC where the product’s Windows client is installed. 2024-07-29 not yet calculated CVE-2024-41143
vultures@jpcert.or.jp
vultures@jpcert.or.jp
  n/a–n/a
  An issue was discovered in litestream v0.3.13. The usage of the ssh.InsecureIgnoreHostKey() disables host key verification, possibly allowing attackers to obtain sensitive information via a man-in-the-middle attack. 2024-07-31 not yet calculated CVE-2024-41254
cve@mitre.org
  n/a–n/a
  Default configurations in the ShareProofVerifier function of filestash v0.4 causes the application to skip the TLS certificate verification process when sending out email verification codes, possibly allowing attackers to access sensitive data via a man-in-the-middle attack. 2024-07-31 not yet calculated CVE-2024-41256
cve@mitre.org
  n/a–n/a
  An issue was discovered in filestash v0.4. The usage of the ssh.InsecureIgnoreHostKey() disables host key verification, possibly allowing attackers to obtain sensitive information via a man-in-the-middle attack. 2024-07-31 not yet calculated CVE-2024-41258
cve@mitre.org
  n/a–n/a
  A static initialization vector (IV) in the encrypt function of netbird v0.28.4 allows attackers to obtain sensitive information. 2024-08-01 not yet calculated CVE-2024-41260
cve@mitre.org
  n/a–n/a
  An issue discovered in casdoor v1.636.0 allows attackers to obtain sensitive information via the ssh.InsecureIgnoreHostKey() method. 2024-08-01 not yet calculated CVE-2024-41264
cve@mitre.org
  n/a–n/a
  An arbitrary file upload vulnerability in the uploadFileAction() function of WonderCMS v3.4.3 allows attackers to execute arbitrary code via a crafted SVG file. 2024-07-30 not yet calculated CVE-2024-41304
cve@mitre.org
  n/a–n/a
  AndServer 2.1.12 is vulnerable to Directory Traversal. 2024-08-02 not yet calculated CVE-2024-41310
cve@mitre.org
  n/a–n/a
  A heap buffer overflow in the function cp_unfilter() (/vendor/cute_png.h) of hicolor v0.5.0 allows attackers to cause a Denial of Service (DoS) via a crafted PNG file. 2024-07-30 not yet calculated CVE-2024-41437
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  A heap buffer overflow in the function cp_block() (/vendor/cute_png.h) of hicolor v0.5.0 allows attackers to cause a Denial of Service (DoS) via a crafted PNG file. 2024-07-30 not yet calculated CVE-2024-41439
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  A stack overflow in the function cp_dynamic() (/vendor/cute_png.h) of hicolor v0.5.0 allows attackers to cause a Denial of Service (DoS) via a crafted PNG file. 2024-07-30 not yet calculated CVE-2024-41443
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An Incorrect Access Control vulnerability in “/admin/benutzer/institution/rechteverwaltung/uebersicht” in Feripro <= v2.2.3 allows remote attackers to get a list of all users and their corresponding privileges. 2024-08-02 not yet calculated CVE-2024-41517
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  An Incorrect Access Control vulnerability in “/admin/programm/<program_id>/export/statistics” in Feripro <= v2.2.3 allows remote attackers to export an XLSX file with information about registrations and participants. 2024-08-02 not yet calculated CVE-2024-41518
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  Feripro <= v2.2.3 is vulnerable to Cross Site Scripting (XSS) via “/admin/programm/<program_id>/zuordnung/veranstaltungen/<event_id>” through the “school” input field. 2024-08-02 not yet calculated CVE-2024-41519
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  Incorrect access control in Himalaya Xiaoya nano smart speaker rom_version 1.6.96 allows a remote attacker to have an unspecified impact. 2024-07-29 not yet calculated CVE-2024-41624
cve@mitre.org
cve@mitre.org
  n/a–n/a
  Stack-based buffer overflow vulnerability in Tenda AC18 V15.03.3.10_EN allows a remote attacker to execute arbitrary code via the ssid parameter at ip/goform/fast_setting_wifi_set. 2024-07-31 not yet calculated CVE-2024-41630
cve@mitre.org
cve@mitre.org
cve@mitre.org
  NaturalIntelligence–fast-xml-parser
  fast-xml-parser is an open source, pure javascript xml parser. a ReDOS exists on currency.js. This vulnerability is fixed in 4.4.1. 2024-07-29 not yet calculated CVE-2024-41818
security-advisories@github.com
security-advisories@github.com
security-advisories@github.com
  OpenText–Filr
  Stored XSS vulnerability has been discovered in OpenText™ Filr product, affecting versions 24.1.1 and 24.2. The vulnerability could cause users to not be warned when clicking links to external sites. 2024-07-31 not yet calculated CVE-2024-4187
security@opentext.com
  OpenText–Documentum Server
  Unprotected Transport of Credentials vulnerability in OpenText™ Documentum™ Server could allow Credential Stuffing.This issue affects Documentum™ Server: from 16.7 through 23.4. 2024-07-30 not yet calculated CVE-2024-4188
security@opentext.com
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode syzbot reported uninit memory usages during map_{lookup,delete}_elem. ========== BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline] bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237 ========== The reproducer should be in the interpreter mode. The C reproducer is trying to run the following bpf prog: 0: (18) r0 = 0x0 2: (18) r1 = map[id:49] 4: (b7) r8 = 16777216 5: (7b) *(u64 *)(r10 -8) = r8 6: (bf) r2 = r10 7: (07) r2 += -229 ^^^^^^^^^^ 8: (b7) r3 = 8 9: (b7) r4 = 0 10: (85) call dev_map_lookup_elem#1543472 11: (95) exit It is due to the “void *key” (r2) passed to the helper. bpf allows uninit stack memory access for bpf prog with the right privileges. This patch uses kmsan_unpoison_memory() to mark the stack as initialized. This should address different syzbot reports on the uninit “void *key” argument during map_{lookup,delete}_elem. 2024-07-29 not yet calculated CVE-2024-42063
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ftruncate: pass a signed offset The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB. Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL. The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake. 2024-07-29 not yet calculated CVE-2024-42084
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <– 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <– 2nd This issue is exposed by commit c7ebd8149ee5 (“usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend”) that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442(“usb: dwc3: Remove DWC3 locking during gadget suspend/resume”) that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume. 2024-07-29 not yet calculated CVE-2024-42085
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: iio: chemical: bme680: Fix overflows in compensate() functions There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 (“iio: chemical: Add support for Bosch BME680 sensor”). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/ 2024-07-29 not yet calculated CVE-2024-42086
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue. 2024-07-29 not yet calculated CVE-2024-42087
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link Commit e70b8dd26711 (“ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link”) removed the codec entry for the ETDM1_OUT_BE dai link entirely instead of replacing it with COMP_EMPTY(). This worked by accident as the remaining COMP_EMPTY() platform entry became the codec entry, and the platform entry became completely empty, effectively the same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn’t do anything for platform entries. This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe() in sound/soc/mediatek/common/mtk-soundcard-driver.c: for_each_card_prelinks(card, i, dai_link) { if (adsp_node && !strncmp(dai_link->name, “AFE_SOF”, strlen(“AFE_SOF”))) dai_link->platforms->of_node = adsp_node; else if (!dai_link->platforms->name && !dai_link->platforms->of_node) dai_link->platforms->of_node = platform_node; } where the code expects the platforms array to have space for at least one entry. Add an COMP_EMPTY() entry so that dai_link->platforms has space. 2024-07-29 not yet calculated CVE-2024-42088
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won’t crash probably due to compiler optimisations. 2024-07-29 not yet calculated CVE-2024-42089
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-42090
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/xe: Check pat.ops before dumping PAT settings We may leave pat.ops unset when running on brand new platform or when running as a VF. While the former is unlikely, the latter is valid (future) use case and will cause NPD when someone will try to dump PAT settings by debugfs. It’s better to check pointer to pat.ops instead of specific .dump hook, as we have this hook always defined for every .ops variant. 2024-07-29 not yet calculated CVE-2024-42091
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: gpio: davinci: Validate the obtained number of IRQs Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won’t exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE. 2024-07-29 not yet calculated CVE-2024-42092
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-42093
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net/iucv: 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. 2024-07-29 not yet calculated CVE-2024-42094
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: serial: 8250_omap: Implementation of Errata i2310 As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution. [0] https://www.ti.com/lit/pdf/sprz536 page 23 2024-07-29 not yet calculated CVE-2024-42095
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-42096
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did. 2024-07-29 not yet calculated CVE-2024-42097
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-29 not yet calculated CVE-2024-42098
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix invalid dereferencing of indirect CCW data pointer Fix invalid dereferencing of indirect CCW data pointer in dasd_eckd_dump_sense() that leads to a kernel panic in error cases. When using indirect addressing for DASD CCWs (IDAW) the CCW CDA pointer does not contain the data address itself but a pointer to the IDAL. This needs to be translated from physical to virtual as well before using it. This dereferencing is also used for dasd_page_cache and also fixed although it is very unlikely that this code path ever gets used. 2024-07-30 not yet calculated CVE-2024-42099
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: common: Don’t call hw_to_ccu_common on hw without common In order to set the rate range of a hw sunxi_ccu_probe calls hw_to_ccu_common() assuming all entries in desc->ccu_clks are contained in a ccu_common struct. This assumption is incorrect and, in consequence, causes invalid pointer de-references. Remove the faulty call. Instead, add one more loop that iterates over the ccu_clks and sets the rate range, if required. 2024-07-30 not yet calculated CVE-2024-42100
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-30 not yet calculated CVE-2024-42101
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: Revert “mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again” Patch series “mm: Avoid possible overflows in dirty throttling”. Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details). This patch (of 2): This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78. The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common – the default settings with 4GB of RAM will trigger this). Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs. We have div64_ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot. 2024-07-30 not yet calculated CVE-2024-42102
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: fix adding block group to a reclaim list and the unused list during reclaim There is a potential parallel list adding for retrying in btrfs_reclaim_bgs_work and adding to the unused list. Since the block group is removed from the reclaim list and it is on a relocation work, it can be added into the unused list in parallel. When that happens, adding it to the reclaim list will corrupt the list head and trigger list corruption like below. Fix it by taking fs_info->unused_bgs_lock. [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104 [177.514][T2585409] list_del corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0) [177.529][T2585409] ————[ cut here ]———— [177.537][T2585409] kernel BUG at lib/list_debug.c:65! [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G W 6.10.0-rc5-kts #1 [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022 [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs] [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72 [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286 [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000 [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40 [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08 [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0 [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000 [177.687][T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000 [177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0 [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000 [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400 [177.742][T2585409] PKRU: 55555554 [177.748][T2585409] Call Trace: [177.753][T2585409] <TASK> [177.759][T2585409] ? __die_body.cold+0x19/0x27 [177.766][T2585409] ? die+0x2e/0x50 [177.772][T2585409] ? do_trap+0x1ea/0x2d0 [177.779][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.788][T2585409] ? do_error_trap+0xa3/0x160 [177.795][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.805][T2585409] ? handle_invalid_op+0x2c/0x40 [177.812][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.820][T2585409] ? exc_invalid_op+0x2d/0x40 [177.827][T2585409] ? asm_exc_invalid_op+0x1a/0x20 [177.834][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.843][T2585409] btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs] There is a similar retry_list code in btrfs_delete_unused_bgs(), but it is safe, AFAICS. Since the block group was in the unused list, the used bytes should be 0 when it was added to the unused list. Then, it checks block_group->{used,reserved,pinned} are still 0 under the block_group->lock. So, they should be still eligible for the unused list, not the reclaim list. The reason it is safe there it’s because because we’re holding space_info->groups_sem in write mode. That means no other task can allocate from the block group, so while we are at deleted_unused_bgs() it’s not possible for other tasks to allocate and deallocate extents from the block group, so it can’t be added to the unused list or the reclaim list by anyone else. The bug can be reproduced by btrfs/166 after a few rounds. In practice this can be hit when relocation cannot find more chunk space and ends with ENOSPC. 2024-07-30 not yet calculated CVE-2024-42103
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: nilfs2: add missing check for inode numbers on directory entries Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis. 2024-07-30 not yet calculated CVE-2024-42104
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix inode number range checks Patch series “nilfs2: fix potential issues related to reserved inodes”. This series fixes one use-after-free issue reported by syzbot, caused by nilfs2’s internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value. This patch (of 3): In the current implementation of nilfs2, “nilfs->ns_first_ino”, which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked. As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly. In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if “ns_first_ino” is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment. Fix these issues by checking the lower bound of “nilfs->ns_first_ino” and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros. Also, change the type of “ns_first_ino” from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time. 2024-07-30 not yet calculated CVE-2024-42105
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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 2024-07-30 not yet calculated CVE-2024-42106
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ice: Don’t process extts if PTP is disabled The ice_ptp_extts_event() function can race with ice_ptp_release() and result in a NULL pointer dereference which leads to a kernel panic. Panic occurs because the ice_ptp_extts_event() function calls ptp_clock_event() with a NULL pointer. The ice driver has already released the PTP clock by the time the interrupt for the next external timestamp event occurs. To fix this, modify the ice_ptp_extts_event() function to check the PTP state and bail early if PTP is not ready. 2024-07-30 not yet calculated CVE-2024-42107
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net: rswitch: Avoid use-after-free in rswitch_poll() The use-after-free is actually in rswitch_tx_free(), which is inlined in rswitch_poll(). Since `skb` and `gq->skbs[gq->dirty]` are in fact the same pointer, the skb is first freed using dev_kfree_skb_any(), then the value in skb->len is used to update the interface statistics. Let’s move around the instructions to use skb->len before the skb is freed. This bug is trivial to reproduce using KFENCE. It will trigger a splat every few packets. A simple ARP request or ICMP echo request is enough. 2024-07-30 not yet calculated CVE-2024-42108
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally flush pending work before notifier syzbot reports: KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45 [..] Workqueue: events nf_tables_trans_destroy_work Call Trace: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline] nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline] nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Problem is that the notifier does a conditional flush, but its possible that the table-to-be-removed is still referenced by transactions being processed by the worker, so we need to flush unconditionally. We could make the flush_work depend on whether we found a table to delete in nf-next to avoid the flush for most cases. AFAICS this problem is only exposed in nf-next, with commit e169285f8c56 (“netfilter: nf_tables: do not store nft_ctx in transaction objects”), with this commit applied there is an unconditional fetch of table->family which is whats triggering the above splat. 2024-07-30 not yet calculated CVE-2024-42109
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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(). 2024-07-30 not yet calculated CVE-2024-42110
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: always do the basic checks for btrfs_qgroup_inherit structure [BUG] Syzbot reports the following regression detected by KASAN: BUG: KASAN: slab-out-of-bounds in btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277 Read of size 8 at addr ffff88814628ca50 by task syz-executor318/5171 CPU: 0 PID: 5171 Comm: syz-executor318 Not tainted 6.10.0-rc2-syzkaller-00010-g2ab795141095 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/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 btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277 create_pending_snapshot+0x1359/0x29b0 fs/btrfs/transaction.c:1854 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1922 btrfs_commit_transaction+0xf20/0x3740 fs/btrfs/transaction.c:2382 create_snapshot+0x6a1/0x9e0 fs/btrfs/ioctl.c:875 btrfs_mksubvol+0x58f/0x710 fs/btrfs/ioctl.c:1029 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1075 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1340 btrfs_ioctl_snap_create_v2+0x1f2/0x3a0 fs/btrfs/ioctl.c:1422 btrfs_ioctl+0x99e/0xc60 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/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 RIP: 0033:0x7fcbf1992509 RSP: 002b:00007fcbf1928218 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcbf1a1f618 RCX: 00007fcbf1992509 RDX: 0000000020000280 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fcbf1a1f610 R08: 00007ffea1298e97 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fcbf19eb660 R13: 00000000200002b8 R14: 00007fcbf19e60c0 R15: 0030656c69662f2e </TASK> And it also pinned it down to commit b5357cb268c4 (“btrfs: qgroup: do not check qgroup inherit if qgroup is disabled”). [CAUSE] That offending commit skips the whole qgroup inherit check if qgroup is not enabled. But that also skips the very basic checks like num_ref_copies/num_excl_copies and the structure size checks. Meaning if a qgroup enable/disable race is happening at the background, and we pass a btrfs_qgroup_inherit structure when the qgroup is disabled, the check would be completely skipped. Then at the time of transaction commitment, qgroup is re-enabled and btrfs_qgroup_inherit() is going to use the incorrect structure and causing the above KASAN error. [FIX] Make btrfs_qgroup_check_inherit() only skip the source qgroup checks. So that even if invalid btrfs_qgroup_inherit structure is passed in, we can still reject invalid ones no matter if qgroup is enabled or not. Furthermore we do already have an extra safety inside btrfs_qgroup_inherit(), which would just ignore invalid qgroup sources, so even if we only skip the qgroup source check we’re still safe. 2024-07-30 not yet calculated CVE-2024-42111
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net: txgbe: free isb resources at the right time When using MSI/INTx interrupt, the shared interrupts are still being handled in the device remove routine, before free IRQs. So isb memory is still read after it is freed. Thus move wx_free_isb_resources() from txgbe_close() to txgbe_remove(). And fix the improper isb free action in txgbe_open() error handling path. 2024-07-30 not yet calculated CVE-2024-42112
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net: txgbe: initialize num_q_vectors for MSI/INTx interrupts When using MSI/INTx interrupts, wx->num_q_vectors is uninitialized. Thus there will be kernel panic in wx_alloc_q_vectors() to allocate queue vectors. 2024-07-30 not yet calculated CVE-2024-42113
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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— 2024-07-30 not yet calculated CVE-2024-42114
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: jffs2: Fix potential illegal address access in jffs2_free_inode During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2_free_inode+0x24/0x48 [ 2430.665233] i_callback+0x24/0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] __do_softirq+0x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffs_inode_info structure. It was found that all variables in the jffs_inode_info structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2_i_init_once, while other members are initialized in the function jffs2_init_inode_info. The function jffs2_init_inode_info is called after iget_locked, but in the iget_locked function, the destroy_inode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, iget_locked may enter the destroy_inode branch as described in the code. Since the destroy_inode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2_i_init_once. 2024-07-30 not yet calculated CVE-2024-42115
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: igc: fix a log entry using uninitialized netdev During successful probe, igc logs this: [ 5.133667] igc 0000:01:00.0 (unnamed net_device) (uninitialized): PHC added ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The reason is that igc_ptp_init() is called very early, even before register_netdev() has been called. So the netdev_info() call works on a partially uninitialized netdev. Fix this by calling igc_ptp_init() after register_netdev(), right after the media autosense check, just as in igb. Add a comment, just as in igb. Now the log message is fine: [ 5.200987] igc 0000:01:00.0 eth0: PHC added 2024-07-30 not yet calculated CVE-2024-42116
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: ASSERT when failing to find index by plane/stream id [WHY] find_disp_cfg_idx_by_plane_id and find_disp_cfg_idx_by_stream_id returns an array index and they return -1 when not found; however, -1 is not a valid index number. [HOW] When this happens, call ASSERT(), and return a positive number (which is fewer than callers’ array size) instead. This fixes 4 OVERRUN and 2 NEGATIVE_RETURNS issues reported by Coverity. 2024-07-30 not yet calculated CVE-2024-42117
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Do not return negative stream id for array [WHY] resource_stream_to_stream_idx returns an array index and it return -1 when not found; however, -1 is not a valid array index number. [HOW] When this happens, call ASSERT(), and return a zero instead. This fixes an OVERRUN and an NEGATIVE_RETURNS issues reported by Coverity. 2024-07-30 not yet calculated CVE-2024-42118
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-30 not yet calculated CVE-2024-42119
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-30 not yet calculated CVE-2024-42120
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index msg_id before read or write [WHAT] msg_id is used as an array index and it cannot be a negative value, and therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1). [HOW] Check whether msg_id is valid before reading and setting. This fixes 4 OVERRUN issues reported by Coverity. 2024-07-30 not yet calculated CVE-2024-42121
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL pointer check for kzalloc [Why & How] Check return pointer of kzalloc before using it. 2024-07-30 not yet calculated CVE-2024-42122
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix double free err_addr pointer warnings In amdgpu_umc_bad_page_polling_timeout, the amdgpu_umc_handle_bad_pages will be run many times so that double free err_addr in some special case. So set the err_addr to NULL to avoid the warnings. 2024-07-30 not yet calculated CVE-2024-42123
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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] 2024-07-30 not yet calculated CVE-2024-42124
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fw: scan offload prohibit all 6 GHz channel if no 6 GHz sband We have some policy via BIOS to block uses of 6 GHz. In this case, 6 GHz sband will be NULL even if it is WiFi 7 chip. So, add NULL handling here to avoid crash. 2024-07-30 not yet calculated CVE-2024-42125
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area. Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don’t see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area. With kernel command line “percpu_alloc=page” we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early: [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] — interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded. 2024-07-30 not yet calculated CVE-2024-42126
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix shared irq handling on driver remove lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. 2024-07-30 not yet calculated CVE-2024-42127
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: leds: an30259a: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module’s remove() is done. led_classdev_unregister() calls module’s led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module’s remove() so use devm API instead. 2024-07-30 not yet calculated CVE-2024-42128
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: leds: mlxreg: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module’s remove() is done. led_classdev_unregister() calls module’s led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module’s remove() so use devm API instead. 2024-07-30 not yet calculated CVE-2024-42129
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: nfc/nci: Add the inconsistency check between the input data length and count write$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB=”610501″], 0xf) Syzbot constructed a write() call with a data length of 3 bytes but a count value of 15, which passed too little data to meet the basic requirements of the function nci_rf_intf_activated_ntf_packet(). Therefore, increasing the comparison between data length and count value to avoid problems caused by inconsistent data length and count. 2024-07-30 not yet calculated CVE-2024-42130
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-30 not yet calculated CVE-2024-42131
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX Syzbot hit warning in hci_conn_del() caused by freeing handle that was not allocated using ida allocator. This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by hci_le_big_sync_established_evt(), which makes code think it’s unset connection. Add same check for handle upper bound as in hci_conn_set_handle() to prevent warning. 2024-07-30 not yet calculated CVE-2024-42132
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Ignore too large handle values in BIG hci_le_big_sync_established_evt is necessary to filter out cases where the handle value is belonging to ida id range, otherwise ida will be erroneously released in hci_conn_cleanup. 2024-07-30 not yet calculated CVE-2024-42133
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: virtio-pci: Check if is_avq is NULL [bug] In the virtio_pci_common.c function vp_del_vqs, vp_dev->is_avq is involved to determine whether it is admin virtqueue, but this function vp_dev->is_avq may be empty. For installations, virtio_pci_legacy does not assign a value to vp_dev->is_avq. [fix] Check whether it is vp_dev->is_avq before use. [test] Test with virsh Attach device Before this patch, the following command would crash the guest system After applying the patch, everything seems to be working fine. 2024-07-30 not yet calculated CVE-2024-42134
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: vhost_task: Handle SIGKILL by flushing work and exiting Instead of lingering until the device is closed, this has us handle SIGKILL by: 1. marking the worker as killed so we no longer try to use it with new virtqueues and new flush operations. 2. setting the virtqueue to worker mapping so no new works are queued. 3. running all the exiting works. 2024-07-30 not yet calculated CVE-2024-42135
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: cdrom: rearrange last_media_change check to avoid unintentional overflow When running syzkaller with the newly reintroduced signed integer wrap sanitizer we encounter this splat: [ 366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33 [ 366.021089] -9223372036854775808 – 346321 cannot be represented in type ‘__s64’ (aka ‘long long’) [ 366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO [ 366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 366.027518] Call Trace: [ 366.027523] <TASK> [ 366.027533] dump_stack_lvl+0x93/0xd0 [ 366.027899] handle_overflow+0x171/0x1b0 [ 366.038787] ata1.00: invalid multi_count 32 ignored [ 366.043924] cdrom_ioctl+0x2c3f/0x2d10 [ 366.063932] ? __pm_runtime_resume+0xe6/0x130 [ 366.071923] sr_block_ioctl+0x15d/0x1d0 [ 366.074624] ? __pfx_sr_block_ioctl+0x10/0x10 [ 366.077642] blkdev_ioctl+0x419/0x500 [ 366.080231] ? __pfx_blkdev_ioctl+0x10/0x10 … Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang. It was re-enabled in the kernel with Commit 557f8c582a9ba8ab (“ubsan: Reintroduce signed overflow sanitizer”). Let’s rearrange the check to not perform any arithmetic, thus not tripping the sanitizer. 2024-07-30 not yet calculated CVE-2024-42136
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot Commit 272970be3dab (“Bluetooth: hci_qca: Fix driver shutdown on closed serdev”) will cause below regression issue: BT can’t be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f (“Bluetooth: btusb: Fix triggering coredump implementation for QCA”) of bluetooth-next tree. commit b23d98d46d28 (“Bluetooth: btusb: Fix triggering coredump implementation for QCA”) of linus mainline tree. 2024-07-30 not yet calculated CVE-2024-42137
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file In case of invalid INI file mlxsw_linecard_types_init() deallocates memory but doesn’t reset pointer to NULL and returns 0. In case of any error occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init() calls mlxsw_linecard_types_fini() which performs memory deallocation again. Add pointer reset to NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. 2024-07-30 not yet calculated CVE-2024-42138
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper extts handling Extts events are disabled and enabled by the application ts2phc. However, in case where the driver is removed when the application is running, a specific extts event remains enabled and can cause a kernel crash. As a side effect, when the driver is reloaded and application is started again, remaining extts event for the channel from a previous run will keep firing and the message “extts on unexpected channel” might be printed to the user. To avoid that, extts events shall be disabled when PTP is released. 2024-07-30 not yet calculated CVE-2024-42139
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: riscv: kexec: Avoid deadlock in kexec crash path If the kexec crash code is called in the interrupt context, the machine_kexec_mask_interrupts() function will trigger a deadlock while trying to acquire the irqdesc spinlock and then deactivate irqchip in irq_set_irqchip_state() function. Unlike arm64, riscv only requires irq_eoi handler to complete EOI and keeping irq_set_irqchip_state() will only leave this possible deadlock without any use. So we simply remove it. 2024-07-30 not yet calculated CVE-2024-42140
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Check socket flag instead of hcon This fixes the following Smatch static checker warning: net/bluetooth/iso.c:1364 iso_sock_recvmsg() error: we previously assumed ‘pi->conn->hcon’ could be null (line 1359) net/bluetooth/iso.c 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg, 1348 size_t len, int flags) 1349 { 1350 struct sock *sk = sock->sk; 1351 struct iso_pinfo *pi = iso_pi(sk); 1352 1353 BT_DBG(“sk %p”, sk); 1354 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) { 1356 lock_sock(sk); 1357 switch (sk->sk_state) { 1358 case BT_CONNECT2: 1359 if (pi->conn->hcon && ^^^^^^^^^^^^^^ If ->hcon is NULL 1360 test_bit(HCI_CONN_PA_SYNC, &pi->conn->hcon->flags)) { 1361 iso_conn_big_sync(sk); 1362 sk->sk_state = BT_LISTEN; 1363 } else { –> 1364 iso_conn_defer_accept(pi->conn->hcon); ^^^^^^^^^^^^^^ then we’re toast 1365 sk->sk_state = BT_CONFIG; 1366 } 1367 release_sock(sk); 1368 return 0; 1369 case BT_CONNECTED: 1370 if (test_bit(BT_SK_PA_SYNC, 2024-07-30 not yet calculated CVE-2024-42141
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-switch, Create ingress ACL when needed Currently, ingress acl is used for three features. It is created only when vport metadata match and prio tag are enabled. But active-backup lag mode also uses it. It is independent of vport metadata match and prio tag. And vport metadata match can be disabled using the following devlink command: # devlink dev param set pci/0000:08:00.0 name esw_port_metadata value false cmode runtime If ingress acl is not created, will hit panic when creating drop rule for active-backup lag mode. If always create it, there will be about 5% performance degradation. Fix it by creating ingress acl when needed. If esw_port_metadata is true, ingress acl exists, then create drop rule using existing ingress acl. If esw_port_metadata is false, create ingress acl and then create drop rule. 2024-07-30 not yet calculated CVE-2024-42142
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: orangefs: fix out-of-bounds fsid access Arnd Bergmann sent a patch to fsdevel, he says: “orangefs_statfs() copies two consecutive fields of the superblock into the statfs structure, which triggers a warning from the string fortification helpers” Jan Kara suggested an alternate way to do the patch to make it more readable. I ran both ideas through xfstests and both seem fine. This patch is based on Jan Kara’s suggestion. 2024-07-30 not yet calculated CVE-2024-42143
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data Verify that lvts_data is not NULL before using it. 2024-07-30 not yet calculated CVE-2024-42144
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-30 not yet calculated CVE-2024-42145
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: drm/xe: Add outer runtime_pm protection to xe_live_ktest@xe_dma_buf Any kunit doing any memory access should get their own runtime_pm outer references since they don’t use the standard driver API entries. In special this dma_buf from the same driver. Found by pre-merge CI on adding WARN calls for unprotected inner callers: <6> [318.639739] # xe_dma_buf_kunit: running xe_test_dmabuf_import_same_driver <4> [318.639957] ————[ cut here ]———— <4> [318.639967] xe 0000:4d:00.0: Missing outer runtime PM protection <4> [318.640049] WARNING: CPU: 117 PID: 3832 at drivers/gpu/drm/xe/xe_pm.c:533 xe_pm_runtime_get_noresume+0x48/0x60 [xe] 2024-07-30 not yet calculated CVE-2024-42146
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/debugfs – Fix debugfs uninit process issue During the zip probe process, the debugfs failure does not stop the probe. When debugfs initialization fails, jumping to the error branch will also release regs, in addition to its own rollback operation. As a result, it may be released repeatedly during the regs uninit process. Therefore, the null check needs to be added to the regs uninit process. 2024-07-30 not yet calculated CVE-2024-42147
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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— 2024-07-30 not yet calculated CVE-2024-42148
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: fs: don’t misleadingly warn during thaw operations The block device may have been frozen before it was claimed by a filesystem. Concurrently another process might try to mount that frozen block device and has temporarily claimed the block device for that purpose causing a concurrent fs_bdev_thaw() to end up here. The mounter is already about to abort mounting because they still saw an elevanted bdev->bd_fsfreeze_count so get_bdev_super() will return NULL in that case. For example, P1 calls dm_suspend() which calls into bdev_freeze() before the block device has been claimed by the filesystem. This brings bdev->bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is required. Now P2 tries to mount that frozen block device. It claims it and checks bdev->bd_fsfreeze_count. As it’s elevated it aborts mounting. In the meantime P3 called dm_resume(). P3 sees that the block device is already claimed by a filesystem and calls into fs_bdev_thaw(). P3 takes a passive reference and realizes that the filesystem isn’t ready yet. P3 puts itself to sleep to wait for the filesystem to become ready. P2 now puts the last active reference to the filesystem and marks it as dying. P3 gets woken, sees that the filesystem is dying and get_bdev_super() fails. 2024-07-30 not yet calculated CVE-2024-42149
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: net: txgbe: remove separate irq request for MSI and INTx When using MSI or INTx interrupts, request_irq() for pdev->irq will conflict with request_threaded_irq() for txgbe->misc.irq, to cause system crash. So remove txgbe_request_irq() for MSI/INTx case, and rename txgbe_request_msix_irqs() since it only request for queue irqs. Add wx->misc_irq_domain to determine whether the driver creates an IRQ domain and threaded request the IRQs. 2024-07-30 not yet calculated CVE-2024-42150
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable Test case dummy_st_ops/dummy_init_ret_value passes NULL as the first parameter of the test_1() function. Mark this parameter as nullable to make verifier aware of such possibility. Otherwise, NULL check in the test_1() code: SEC(“struct_ops/test_1”) int BPF_PROG(test_1, struct bpf_dummy_ops_state *state) { if (!state) return …; … access state … } Might be removed by verifier, thus triggering NULL pointer dereference under certain conditions. 2024-07-30 not yet calculated CVE-2024-42151
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window. 2024-07-30 not yet calculated CVE-2024-42152
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether. 2024-07-30 not yet calculated CVE-2024-42153
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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). 2024-07-30 not yet calculated CVE-2024-42154
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-30 not yet calculated CVE-2024-42155
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [Changes from V1: – Use a default branch in the switch statement to initialize `val’.] GCC warns that `val’ may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: […] unsigned long long val; […] switch (__CORE_RELO(s, field, BYTE_SIZE)) { case 1: val = *(const unsigned char *)p; break; case 2: val = *(const unsigned short *)p; break; case 4: val = *(const unsigned int *)p; break; case 8: val = *(const unsigned long long *)p; break; } […] val; } This patch adds a default entry in the switch statement that sets `val’ to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions. 2024-07-30 not yet calculated CVE-2024-42161
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  Linux–Linux
  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. 2024-07-30 not yet calculated CVE-2024-42162
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
  n/a–n/a
  server.c in Neat VNC (aka neatvnc) before 0.8.1 does not properly validate the security type, a related issue to CVE-2006-2369. 2024-08-02 not yet calculated CVE-2024-42458
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
  n/a–n/a
  In the Elliptic package 6.5.6 for Node.js, ECDSA signature malleability occurs because BER-encoded signatures are allowed. 2024-08-02 not yet calculated CVE-2024-42461
cve@mitre.org
  Concrete CMS–Concrete CMS
  Concrete CMS versions 9.0.0 through 9.3.2 are affected by a stored XSS vulnerability in the generate dashboard board instance functionality. The Name input field does not check the input sufficiently letting a rogue administrator hav the capability to inject malicious JavaScript code. The Concrete CMS security team gave this vulnerability a CVSS v3.1 score of 3.1 with a vector of AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator  and a CVSS v4 score of 1.8 with a vector of CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N Thanks fhAnso for reporting. 2024-08-01 not yet calculated CVE-2024-4353
ff5b8ace-8b95-4078-9743-eac1ca5451de
  parisneo–parisneo/lollms-webui
  In parisneo/lollms-webui version v9.8, the lollms_binding_infos is missing the client_id parameter, which leads to multiple security vulnerabilities. Specifically, the endpoints /reload_binding, /install_binding, /reinstall_binding, /unInstall_binding, /set_active_binding_settings, and /update_binding_settings are susceptible to CSRF attacks and local attacks. An attacker can exploit this vulnerability to perform unauthorized actions on the victim’s machine. 2024-08-01 not yet calculated CVE-2024-6040
security@huntr.dev
  M-Files Corporation–Hubshare
  Reflected XSS in M-Files Hubshare before version 5.0.6.0 allows an attacker to execute arbitrary JavaScript code in the context of the victim’s browser session 2024-07-29 not yet calculated CVE-2024-6124
security@m-files.com
  Unknown– 
  The پلاگین پرداخت دلخواه WordPress plugin through 2.9.8 does not have CSRF check in place when resetting its form fields, which could allow attackers to make a logged in admin perform such action via a CSRF attack 2024-07-30 not yet calculated CVE-2024-6230
contact@wpscan.com
  Rockwell Automation–ControlLogix 5580 (1756-L8z)
  A vulnerability exists in Rockwell Automation affected products that allows a threat actor to bypass the Trusted® Slot feature in a ControlLogix® controller. If exploited on any affected module in a 1756 chassis, a threat actor could potentially execute CIP commands that modify user projects and/or device configuration on a Logix controller in the chassis. 2024-08-01 not yet calculated CVE-2024-6242
PSIRT@rockwellautomation.com
  gaizhenbiao–gaizhenbiao/chuanhuchatgpt
  A vulnerability in the JSON file handling of gaizhenbiao/chuanhuchatgpt version 20240410 allows any user to delete any JSON file on the server, including critical configuration files such as `config.json` and `ds_config_chatbot.json`. This issue arises due to improper validation of file paths, enabling directory traversal attacks. An attacker can exploit this vulnerability to disrupt the functioning of the system, manipulate settings, or potentially cause data loss or corruption. 2024-07-31 not yet calculated CVE-2024-6255
security@huntr.dev
  Unknown–Quiz and Survey Master (QSM)
  The Quiz and Survey Master (QSM) WordPress plugin before 9.1.0 does not properly sanitise and escape some of its Quizz settings, which could allow high privilege users such as contributor to perform Stored Cross-Site Scripting attacks 2024-08-03 not yet calculated CVE-2024-6390
contact@wpscan.com
  Unknown–UsersWP
  The UsersWP WordPress plugin before 1.2.12 uses predictable filenames when an admin generates an export, which could allow unauthenticated attackers to download them and retrieve sensitive information such as IP, username, and email address 2024-08-03 not yet calculated CVE-2024-6477
contact@wpscan.com
  Unknown–Light Poll
  The Light Poll WordPress plugin through 1.0.0 does not have CSRF checks when deleting polls, which could allow attackers to make logged in users perform such action via a CSRF attack 2024-08-01 not yet calculated CVE-2024-6496
contact@wpscan.com
  Unknown–Zephyr Project Manager
  The Zephyr Project Manager WordPress plugin before 3.3.99 does not sanitise and escape some of its settings, which could allow high privilege users such as editors and admins to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup) 2024-07-30 not yet calculated CVE-2024-6536
contact@wpscan.com
  aimhubio–aimhubio/aim
  A stored cross-site scripting (XSS) vulnerability exists in aimhubio/aim version 3.19.3. The vulnerability arises from the improper neutralization of input during web page generation, specifically in the logs-tab for runs. The terminal output logs are displayed using the `dangerouslySetInnerHTML` function in React, which is susceptible to XSS attacks. An attacker can exploit this vulnerability by injecting malicious scripts into the logs, which will be executed when a user views the logs-tab. 2024-07-29 not yet calculated CVE-2024-6578
security@huntr.dev
  Mikafon Electronic Inc.–Mikafon MA7
  Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) vulnerability in Mikafon Electronic Inc. Mikafon MA7 allows SQL Injection.This issue affects Mikafon MA7: from v3.0 before v3.1. 2024-07-30 not yet calculated CVE-2024-6699
iletisim@usom.gov.tr
  M-Files Corporation–Hubshare
  Stored XSS in M-Files Hubshare versions before 5.0.6.0 allows an authenticated attacker to execute arbitrary JavaScript in user’s browser session 2024-07-29 not yet calculated CVE-2024-6881
security@m-files.com
  Bitdefender–GravityZone Update Server
  A verbose error handling issue in the proxy service implemented in the GravityZone Update Server allows an attacker to cause a server-side request forgery. This issue only affects GravityZone Console versions before 6.38.1-5 running only on premise. 2024-07-31 not yet calculated CVE-2024-6980
cve-requests@bitdefender.com
  Netflix–Dispatch
  Dispatch’s notification service uses Jinja templates to generate messages to users. Jinja permits code execution within blocks, which were neither properly sanitized nor sandboxed. This vulnerability enables users to construct command line scripts in their custom message templates, which are then executed whenever these notifications are rendered and sent out. 2024-08-01 not yet calculated CVE-2024-7093
security-report@netflix.com
  Stackposts–Social Marketing Tool
  Improper Neutralization of Input During Web Page Generation vulnerability in Stackposts Social Marketing Tool allows Cross-site Scripting (XSS) attack. By submitting the payload in the username during registration, it can be executed later in the application panel. This could lead to the unauthorised acquisition of information (e.g. cookies from a logged-in user). After multiple attempts to contact the vendor we did not receive any answer. Our team has confirmed the existence of this vulnerability. We suppose this issue affects Social Marketing Tool in all versions. 2024-07-30 not yet calculated CVE-2024-7127
cvd@cert.pl
cvd@cert.pl
cvd@cert.pl
cvd@cert.pl
  CoolKit–eWeLink Cloud Service
  When the device is shared, the homepage module are before 2.19.0  in eWeLink Cloud Service allows Secondary user to take over devices as primary user via sharing unnecessary device-sensitive information. 2024-07-31 not yet calculated CVE-2024-7205
68870bb1-d075-4169-957d-e580b18692b9
  HostGator–HostGator
  A vulnerability in multi-tenant hosting allows an authenticated sender to spoof the identity of a shared, hosted domain, thus bypass security measures provided by DMARC (or SPF or DKIM) policies. 2024-07-30 not yet calculated CVE-2024-7208
cret@cert.org
  NetWin–NetWin
  A vulnerability exists in the use of shared SPF records in multi-tenant hosting providers, allowing attackers to use network authorization to be abused to spoof the email identify of the sender. 2024-07-30 not yet calculated CVE-2024-7209
cret@cert.org
cret@cert.org
  Comodo–Internet Security Pro
  Comodo Internet Security Pro Directory Traversal Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Comodo Internet Security Pro. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the update mechanism. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-19055. 2024-07-29 not yet calculated CVE-2024-7248
zdi-disclosures@trendmicro.com
  Comodo–Firewall
  Comodo Firewall Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Comodo Firewall. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the cmdagent executable. By creating a symbolic link, an attacker can abuse the application to delete a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-21794. 2024-07-29 not yet calculated CVE-2024-7249
zdi-disclosures@trendmicro.com
  Comodo–Internet Security Pro
  Comodo Internet Security Pro cmdagent Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Comodo Internet Security Pro. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the cmdagent executable. By creating a symbolic link, an attacker can abuse the agent to delete a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-22829. 2024-07-29 not yet calculated CVE-2024-7250
zdi-disclosures@trendmicro.com
  Comodo–Internet Security Pro
  Comodo Internet Security Pro cmdagent Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Comodo Internet Security Pro. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the cmdagent executable. By creating a symbolic link, an attacker can abuse the agent to create a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-22832. 2024-07-29 not yet calculated CVE-2024-7251
zdi-disclosures@trendmicro.com
  Comodo–Internet Security Pro
  Comodo Internet Security Pro cmdagent Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Comodo Internet Security Pro. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the cmdagent executable. By creating a symbolic link, an attacker can abuse the agent to delete a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-22831. 2024-07-29 not yet calculated CVE-2024-7252
zdi-disclosures@trendmicro.com
  Google–Chrome
  Out of bounds read in WebTransport in Google Chrome prior to 127.0.6533.88 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High) 2024-08-01 not yet calculated CVE-2024-7255
chrome-cve-admin@google.com
chrome-cve-admin@google.com
  curl–curl
  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. 2024-07-31 not yet calculated CVE-2024-7264
2499f714-1537-4658-8207-48ae4bb9eae9
2499f714-1537-4658-8207-48ae4bb9eae9
2499f714-1537-4658-8207-48ae4bb9eae9
2499f714-1537-4658-8207-48ae4bb9eae9