alsendo_sp._z_o._o. — apaczka
  Improper access control vulnerability in Apaczka plugin for PrestaShop allows information gathering from saved templates without authentication.This issue affects Apaczka plugin for PrestaShop from v1 through v4. 2024-04-04 not yet calculated CVE-2024-2759
cvd@cert.pl
cvd@cert.pl amphp — amphp/http-client
  amphp/http will collect CONTINUATION frames in an unbounded buffer and will not check a limit until it has received the set END_HEADERS flag, resulting in an OOM crash. 2024-04-03 not yet calculated CVE-2024-2653
cret@cert.org
cret@cert.org apache_software_foundation — apache_cloudstack
  By default the CloudStack management server honours the x-forwarded-for HTTP header and logs it as the source IP of an API request. This could lead to authentication bypass and other operational problems should an attacker decide to spoof their IP address this way. Users are recommended to upgrade to CloudStack version 4.18.1.1 or 4.19.0.1, which fixes this issue. 2024-04-04 not yet calculated CVE-2024-29006
security@apache.org apache_software_foundation — apache_cloudstack
  The CloudStack management server and secondary storage VM could be tricked into making requests to restricted or random resources by means of following 301 HTTP redirects presented by external servers when downloading templates or ISOs. Users are recommended to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue. 2024-04-04 not yet calculated CVE-2024-29007
security@apache.org apache_software_foundation — apache_cloudstack
  A problem has been identified in the CloudStack additional VM configuration (extraconfig) feature which can be misused by anyone who has privilege to deploy a VM instance or configure settings of an already deployed VM instance, to configure additional VM configuration even when the feature is not explicitly enabled by the administrator. In a KVM based CloudStack environment, an attacker can exploit this issue to attach host devices such as storage disks, and PCI and USB devices such as network adapters and GPUs, in a regular VM instance that can be further exploited to gain access to the underlying network and storage infrastructure resources, and access any VM instance disks on the local storage. Users are advised to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue. 2024-04-04 not yet calculated CVE-2024-29008
security@apache.org apache_software_foundation — apache_http_server
  Faulty input validation in the core of Apache allows malicious or exploitable backend/content generators to split HTTP responses. This issue affects Apache HTTP Server: through 2.4.58. 2024-04-04 not yet calculated CVE-2023-38709
security@apache.org apache_software_foundation — apache_http_server
  HTTP Response splitting in multiple modules in Apache HTTP Server allows an attacker that can inject malicious response headers into backend applications to cause an HTTP desynchronization attack. Users are recommended to upgrade to version 2.4.59, which fixes this issue. 2024-04-04 not yet calculated CVE-2024-24795
security@apache.org apache_software_foundation — apache_http_server
  HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion. 2024-04-04 not yet calculated CVE-2024-27316
security@apache.org apache_software_foundation — apache_nimble
  Loop with Unreachable Exit Condition (‘Infinite Loop’) vulnerability in Apache NimBLE.  Specially crafted GATT operation can cause infinite loop in GATT server leading to denial of service in Bluetooth stack or device. This issue affects Apache NimBLE: through 1.6.0. Users are recommended to upgrade to version 1.7.0, which fixes the issue. 2024-04-06 not yet calculated CVE-2024-24746
security@apache.org ays_pro_plugins — survey_maker
  Survey Maker prior to 3.6.4 contains a stored cross-site scripting vulnerability. If this vulnerability is exploited, an arbitrary script may be executed on the web browser of the user who is logging in to the website using the product with the administrative privilege. 2024-04-03 not yet calculated CVE-2023-34423
vultures@jpcert.or.jp
vultures@jpcert.or.jp ays_pro_plugins — survey_maker
  Insufficient verification of data authenticity issue in Survey Maker prior to 3.6.4 allows a remote unauthenticated attacker to spoof an IP address when posting. 2024-04-03 not yet calculated CVE-2023-35764
vultures@jpcert.or.jp
vultures@jpcert.or.jp centreon — centreon
  Centreon updateDirectory SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. Authentication is required to exploit this vulnerability. The specific flaw exists within the updateDirectory function. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-22294. 2024-04-01 not yet calculated CVE-2024-0637
zdi-disclosures@trendmicro.com centreon — centreon
  Centreon updateGroups SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. Authentication is required to exploit this vulnerability. The specific flaw exists within the updateGroups function. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-22295. 2024-04-01 not yet calculated CVE-2024-23115
zdi-disclosures@trendmicro.com centreon — centreon
  Centreon updateLCARelation SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. Authentication is required to exploit this vulnerability. The specific flaw exists within the updateLCARelation function. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-22296. 2024-04-01 not yet calculated CVE-2024-23116
zdi-disclosures@trendmicro.com centreon — centreon
  Centreon updateContactServiceCommands SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. Authentication is required to exploit this vulnerability. The specific flaw exists within the updateContactServiceCommands function. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-22297. 2024-04-01 not yet calculated CVE-2024-23117
zdi-disclosures@trendmicro.com centreon — centreon
  Centreon updateContactHostCommands SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. Authentication is required to exploit this vulnerability. The specific flaw exists within the updateContactHostCommands function. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-22298. 2024-04-01 not yet calculated CVE-2024-23118
zdi-disclosures@trendmicro.com centreon — centreon
  Centreon insertGraphTemplate SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. Authentication is required to exploit this vulnerability. The specific flaw exists within the insertGraphTemplate function. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-22339. 2024-04-01 not yet calculated CVE-2024-23119
zdi-disclosures@trendmicro.com elecom_co.,ltd. — wrc-x3200gst3-b
  OS command injection vulnerability in WRC-X3200GST3-B v1.25 and earlier, and WRC-G01-W v1.24 and earlier allows a network-adjacent unauthenticated attacker to execute arbitrary OS commands by sending a specially crafted request to the product. 2024-04-04 not yet calculated CVE-2024-25568
vultures@jpcert.or.jp
vultures@jpcert.or.jp elecom_co.,ltd. — wrc-x3200gst3-b
  OS command injection vulnerability in WRC-X3200GST3-B v1.25 and earlier, and WRC-G01-W v1.24 and earlier allows a network-adjacent attacker with credentials to execute arbitrary OS commands by sending a specially crafted request to the product. 2024-04-04 not yet calculated CVE-2024-26258
vultures@jpcert.or.jp
vultures@jpcert.or.jp elecom_co.ltd. — wrc-x3200gst3-b
  WRC-X3200GST3-B v1.25 and earlier, and WRC-G01-W v1.24 and earlier allow a network-adjacent unauthenticated attacker to obtain the configuration file containing sensitive information by sending a specially crafted request. 2024-04-04 not yet calculated CVE-2024-29225
vultures@jpcert.or.jp
vultures@jpcert.or.jp foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22499. 2024-04-03 not yet calculated CVE-2024-30322
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader template Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of template objects. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22501. 2024-04-03 not yet calculated CVE-2024-30323
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Doc Object Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22576. 2024-04-03 not yet calculated CVE-2024-30324
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22592. 2024-04-03 not yet calculated CVE-2024-30325
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Doc Object Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22593. 2024-04-03 not yet calculated CVE-2024-30326
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader template Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of template objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22632. 2024-04-03 not yet calculated CVE-2024-30327
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22633. 2024-04-03 not yet calculated CVE-2024-30328
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Annotation Use-After-Free Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Annotation objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22634. 2024-04-03 not yet calculated CVE-2024-30329
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22636. 2024-04-03 not yet calculated CVE-2024-30330
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22637. 2024-04-03 not yet calculated CVE-2024-30331
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Doc Object Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22638. 2024-04-03 not yet calculated CVE-2024-30332
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Doc Object Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22639. 2024-04-03 not yet calculated CVE-2024-30333
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Doc Object Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22640. 2024-04-03 not yet calculated CVE-2024-30334
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Annotation Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Annotation objects. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22641. 2024-04-02 not yet calculated CVE-2024-30335
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22642. 2024-04-02 not yet calculated CVE-2024-30336
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Acroforms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22704. 2024-04-02 not yet calculated CVE-2024-30337
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Doc Object Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22705. 2024-04-02 not yet calculated CVE-2024-30338
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Acroforms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22706. 2024-04-02 not yet calculated CVE-2024-30339
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Annotation Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Annotation objects. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22707. 2024-04-02 not yet calculated CVE-2024-30340
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Doc Object Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22709. 2024-04-02 not yet calculated CVE-2024-30341
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Annotation Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Annotation objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22720. 2024-04-02 not yet calculated CVE-2024-30342
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Annotation Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Annotation objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22721. 2024-04-02 not yet calculated CVE-2024-30343
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Acroforms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22733. 2024-04-02 not yet calculated CVE-2024-30344
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22742. 2024-04-02 not yet calculated CVE-2024-30345
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22745. 2024-04-02 not yet calculated CVE-2024-30346
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader U3D File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22910. 2024-04-02 not yet calculated CVE-2024-30347
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader U3D File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22911. 2024-04-02 not yet calculated CVE-2024-30348
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader U3D File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22912. 2024-04-02 not yet calculated CVE-2024-30349
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader Annotation Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Annotation objects. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22708. 2024-04-02 not yet calculated CVE-2024-30350
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22799. 2024-04-02 not yet calculated CVE-2024-30351
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22800. 2024-04-02 not yet calculated CVE-2024-30352
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22807. 2024-04-02 not yet calculated CVE-2024-30353
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22808. 2024-04-02 not yet calculated CVE-2024-30354
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22809. 2024-04-02 not yet calculated CVE-2024-30355
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Doc objects in AcroForms. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22811. 2024-04-02 not yet calculated CVE-2024-30356
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Annotation Type Confusion Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of Annotation objects in AcroForms. The issue results from the lack of proper validation of user-supplied data, which can result in a type confusion condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22818. 2024-04-02 not yet calculated CVE-2024-30357
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm User-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22821. 2024-04-02 not yet calculated CVE-2024-30358
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm 3D Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of 3D objects in AcroForms. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22888. 2024-04-02 not yet calculated CVE-2024-30359
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22797. 2024-04-02 not yet calculated CVE-2024-30360
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22877. 2024-04-02 not yet calculated CVE-2024-30361
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader PDF File Parsing Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22798. 2024-04-02 not yet calculated CVE-2024-30362
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader U3D File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-23008. 2024-04-02 not yet calculated CVE-2024-30363
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader U3D File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-23009. 2024-04-02 not yet calculated CVE-2024-30364
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22947. 2024-04-02 not yet calculated CVE-2024-30365
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-23002. 2024-04-03 not yet calculated CVE-2024-30366
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-23013. 2024-04-02 not yet calculated CVE-2024-30367
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com foxit — pdf_reader
  Foxit PDF Reader AcroForm Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PDF Reader. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-23355. 2024-04-02 not yet calculated CVE-2024-30371
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com fujidenolo_solutions_co._ltd. — sonicdicom_media_viewer
  Uncontrolled search path element issue exists in SonicDICOM Media Viewer 2.3.2 and earlier, which may lead to insecurely loading Dynamic Link Libraries. As a result, arbitrary code may be executed with the privileges of the running application. 2024-04-03 not yet calculated CVE-2024-29734
vultures@jpcert.or.jp go_standard_library — net/http
  An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request’s headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection. 2024-04-04 not yet calculated CVE-2023-45288
security@golang.org
security@golang.org
security@golang.org
security@golang.org google — android
  In tmu_get_tr_stats of tmu.c, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-27231
dsap-vuln-management@google.com google — android
  In asn1_ec_pkey_parse of asn1_common.c, there is a possible OOB read due to a missing null check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-27232
dsap-vuln-management@google.com google — android
  In gov_init, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29738
dsap-vuln-management@google.com google — android
  In tmu_get_temp_lut of tmu.c, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29739
dsap-vuln-management@google.com google — android
  In tmu_set_table of tmu.c, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29740
dsap-vuln-management@google.com google — android
  In pblS2mpuResume of s2mpu.c, there is a possible mitigation bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29741
dsap-vuln-management@google.com google — android
  In apply_minlock_constraint of dvfs.c, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29742
dsap-vuln-management@google.com google — android
  In tmu_set_temp_lut of tmu.c, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29743
dsap-vuln-management@google.com google — android
  In tmu_get_gov_time_windows, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29744
dsap-vuln-management@google.com google — android
  there is a possible Information Disclosure due to uninitialized data. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29745
dsap-vuln-management@google.com google — android
  In lpm_req_handler of lpm.c, there is a possible out of bounds write due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29746
dsap-vuln-management@google.com google — android
  In _dvfs_get_lv of dvfs.c, there is a possible out of bounds read due to a missing null check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29747
dsap-vuln-management@google.com google — android
  there is a possible way to bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29748
dsap-vuln-management@google.com google — android
  In tmu_set_tr_thresholds of tmu.c, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29749
dsap-vuln-management@google.com google — android
  In km_exp_did_inner of kmv.c, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29750
dsap-vuln-management@google.com google — android
  In asn1_ec_pkey_parse_p384 of asn1_common.c, there is a possible OOB Read due to a missing null check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29751
dsap-vuln-management@google.com google — android
  In tmu_set_tr_num_thresholds of tmu.c, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29752
dsap-vuln-management@google.com google — android
  In tmu_set_control_temp_step of tmu.c, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29753
dsap-vuln-management@google.com google — android
  In TMU_IPC_GET_TABLE, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29754
dsap-vuln-management@google.com google — android
  In tmu_get_pi of tmu.c, there is a possible out of bounds read due to improper input validation. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29755
dsap-vuln-management@google.com google — android
  In afe_callback of q6afe.c, there is a possible out of bounds write due to a buffer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29756
dsap-vuln-management@google.com google — android
  there is a possible permission bypass due to Debug certs being allowlisted. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29757
dsap-vuln-management@google.com google — android
  In tmu_get_tr_num_thresholds of tmu.c, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29782
dsap-vuln-management@google.com google — android
  In tmu_get_tr_thresholds, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. 2024-04-05 not yet calculated CVE-2024-29783
dsap-vuln-management@google.com google — chrome
  Inappropriate implementation in V8 in Google Chrome prior to 123.0.6312.105 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High) 2024-04-06 not yet calculated CVE-2024-3156
chrome-cve-admin@google.com
chrome-cve-admin@google.com google — chrome
  Use after free in Bookmarks in Google Chrome prior to 123.0.6312.105 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) 2024-04-06 not yet calculated CVE-2024-3158
chrome-cve-admin@google.com
chrome-cve-admin@google.com google — chrome
  Out of bounds memory access in V8 in Google Chrome prior to 123.0.6312.105 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page. (Chromium security severity: High) 2024-04-06 not yet calculated CVE-2024-3159
chrome-cve-admin@google.com
chrome-cve-admin@google.com ivanti — connect_secure
  A heap overflow vulnerability in IPSec component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure allows an unauthenticated malicious user to send specially crafted requests in-order-to crash the service thereby causing a DoS attack. In certain conditions this may lead to execution of arbitrary code 2024-04-04 not yet calculated CVE-2024-21894
support@hackerone.com ivanti — connect_secure
  An XML entity expansion or XEE vulnerability in SAML component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure allows an unauthenticated attacker to send specially crafted XML requests in-order-to temporarily cause resource exhaustion thereby resulting in a limited-time DoS. 2024-04-04 not yet calculated CVE-2024-22023
support@hackerone.com ivanti — connect_secure
  A null pointer dereference vulnerability in IPSec component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure allows an unauthenticated malicious user to send specially crafted requests in-order-to crash the service thereby causing a DoS attack 2024-04-04 not yet calculated CVE-2024-22052
support@hackerone.com ivanti — connect_secure
  A heap overflow vulnerability in IPSec component of Ivanti Connect Secure (9.x 22.x) and Ivanti Policy Secure allows an unauthenticated malicious user to send specially crafted requests in-order-to crash the service thereby causing a DoS attack or in certain conditions read contents from memory. 2024-04-04 not yet calculated CVE-2024-22053
support@hackerone.com kofax — power_pdf
  Kofax Power PDF GIF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of GIF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-21976. 2024-04-01 not yet calculated CVE-2024-27333
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF JPG File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of JPG files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-21978. 2024-04-02 not yet calculated CVE-2024-27334
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PNG File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of PNG files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22018. 2024-04-03 not yet calculated CVE-2024-27335
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PNG File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PNG files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22022. 2024-04-03 not yet calculated CVE-2024-27336
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF TIF File Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of TIF files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22033. 2024-04-03 not yet calculated CVE-2024-27337
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF app response Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the implementation of the app.response method. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22588. 2024-04-03 not yet calculated CVE-2024-27338
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22925. 2024-04-03 not yet calculated CVE-2024-27339
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22926. 2024-04-03 not yet calculated CVE-2024-27340
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22927. 2024-04-03 not yet calculated CVE-2024-27341
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22928. 2024-04-03 not yet calculated CVE-2024-27342
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22929. 2024-04-03 not yet calculated CVE-2024-27343
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Memory Corruption Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22931. 2024-04-03 not yet calculated CVE-2024-27344
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22932. 2024-04-03 not yet calculated CVE-2024-27345
zdi-disclosures@trendmicro.com kofax — power_pdf
  Kofax Power PDF PDF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Kofax Power PDF. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22934. 2024-04-03 not yet calculated CVE-2024-27346
zdi-disclosures@trendmicro.com linux — linux
  In the Linux kernel, the following vulnerability has been resolved: blk-iocost: Fix an UBSAN shift-out-of-bounds warning When iocg_kick_delay() is called from a CPU different than the one which set the delay, @now may be in the past of @iocg->delay_at leading to the following warning: UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23 shift exponent 18446744073709 is too large for 64-bit type ‘u64’ (aka ‘unsigned long long’) … Call Trace: <TASK> dump_stack_lvl+0x79/0xc0 __ubsan_handle_shift_out_of_bounds+0x2ab/0x300 iocg_kick_delay+0x222/0x230 ioc_rqos_merge+0x1d7/0x2c0 __rq_qos_merge+0x2c/0x80 bio_attempt_back_merge+0x83/0x190 blk_attempt_plug_merge+0x101/0x150 blk_mq_submit_bio+0x2b1/0x720 submit_bio_noacct_nocheck+0x320/0x3e0 __swap_writepage+0x2ab/0x9d0 The underflow itself doesn’t really affect the behavior in any meaningful way; however, the past timestamp may exaggerate the delay amount calculated later in the code, which shouldn’t be a material problem given the nature of the delay mechanism. If @now is in the past, this CPU is racing another CPU which recently set up the delay and there’s nothing this CPU can contribute w.r.t. the delay. Let’s bail early from iocg_kick_delay() in such cases. 2024-04-02 not yet calculated CVE-2023-52630
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: Fix an NULL dereference bug The issue here is when this is called from ntfs_load_attr_list(). The “size” comes from le32_to_cpu(attr->res.data_size) so it can’t overflow on a 64bit systems but on 32bit systems the “+ 1023” can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line. 2024-04-02 not yet calculated CVE-2023-52631
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/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted —————————————————— kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu –> &info->lock#2 –> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 —- —- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu); 2024-04-02 not yet calculated CVE-2023-52632
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: um: time-travel: fix time corruption In ‘basic’ time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that’s incompatible with the forward, and we’ll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled. 2024-04-02 not yet calculated CVE-2023-52633
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 disable_otg_wa logic [Why] When switching to another HDMI mode, we are unnecesarilly disabling/enabling FIFO causing both HPO and DIG registers to be set at the same time when only HPO is supposed to be set. This can lead to a system hang the next time we change refresh rates as there are cases when we don’t disable OTG/FIFO but FIFO is enabled when it isn’t supposed to be. [How] Removing the enable/disable FIFO entirely. 2024-04-02 not yet calculated CVE-2023-52634
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Synchronize devfreq_monitor_[start/stop] There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1]. while true do echo “simple_ondemand” > /sys/class/devfreq/1d84000.ufshc/governor echo “performance” > /sys/class/devfreq/1d84000.ufshc/governor done It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled. Let’s use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted. [1] … .. <idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 <idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c <idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 … [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=–) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8 —truncated— 2024-04-02 not yet calculated CVE-2023-52635
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: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket. Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data(). The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client. The sparse-read state machine assumes that it’s a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let’s reuse cursor->total_resid. Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data. And then osd_sparse_read() could continue where it left off. [ idryomov: changelog ] 2024-04-02 not yet calculated CVE-2023-52636
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: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(…, SO_J1939_FILTER, …) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can] can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ? __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ? _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 </IRQ> <TASK> __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ? __pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ? __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ? __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 348: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0 __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 2024-04-03 not yet calculated CVE-2023-52637
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: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: – j1939_socks_lock – active_session_list_lock – sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change] 2024-04-03 not yet calculated CVE-2023-52638
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: KVM: s390: vsie: fix race during shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { […] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm; Let children inherit the private field of the parent. 2024-04-03 not yet calculated CVE-2023-52639
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: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea. 2024-04-03 not yet calculated CVE-2023-52640
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 NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there. 2024-04-03 not yet calculated CVE-2023-52641
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: misc: ljca: Fix double free in error handling path When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function ljca_auxdev_release calls kfree(auxdev->dev.platform_data) to free the parameter data of the function ljca_new_client_device. The callers of ljca_new_client_device shouldn’t call kfree() again in the error handling path to free the platform data. Fix this by cleaning up the redundant kfree() in all callers and adding kfree() the passed in platform_data on errors which happen before auxiliary_device_init() succeeds . 2024-04-01 not yet calculated CVE-2024-26653
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: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below: (Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | … | run_spu_dma() //worker | mod_timer() flush_work() | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() | run_spu_dma() //worker … | dreamcastcard->channel-> //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed. 2024-04-01 not yet calculated CVE-2024-26654
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: Fix memory leak in posix_clock_open() If the clk ops.open() function returns an error, we don’t release the pccontext we allocated for this clock. Re-organize the code slightly to make it all more obvious. 2024-04-01 not yet calculated CVE-2024-26655
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 use-after-free bug The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>. For example the following code: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; int ret; arg.addr = 0xffffffffffff0000; arg.size = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg); } Due to the address and size are not valid there is a failure in amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert-> check_shl_overflow, but we even the amdgpu_hmm_register failure we still call amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address. The following stack is below when the issue is reproduced when Kazan is enabled: [ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000 [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [ +0.000010] Call Trace: [ +0.000006] <TASK> [ +0.000007] ? show_regs+0x6a/0x80 [ +0.000018] ? __warn+0xa5/0x1b0 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000018] ? report_bug+0x24a/0x290 [ +0.000022] ? handle_bug+0x46/0x90 [ +0.000015] ? exc_invalid_op+0x19/0x50 [ +0.000016] ? asm_exc_invalid_op+0x1b/0x20 [ +0.000017] ? kasan_save_stack+0x26/0x50 [ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340 [ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10 [ +0.000017] ? kasan_save_alloc_info+0x1e/0x30 [ +0.000018] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_kmalloc+0xb1/0xc0 [ +0.000018] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_read+0x11/0x20 [ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu] [ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu] [ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu] [ +0.004291] ? do_syscall_64+0x5f/0xe0 [ +0.000023] ? srso_return_thunk+0x5/0x5f [ +0.000017] drm_gem_object_free+0x3b/0x50 [drm] [ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu] [ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004270] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __this_cpu_preempt_check+0x13/0x20 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm] [ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm] [ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm] [ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d —truncated— 2024-04-02 not yet calculated CVE-2024-26656
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/sched: fix null-ptr-deref in init entity The bug can be triggered by sending an amdgpu_cs_wait_ioctl to the AMDGPU DRM driver on any ASICs with valid context. The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>. For example the following code: static void Syzkaller2(int fd) { union drm_amdgpu_ctx arg1; union drm_amdgpu_wait_cs arg2; arg1.in.op = AMDGPU_CTX_OP_ALLOC_CTX; ret = drmIoctl(fd, 0x140106442 /* amdgpu_ctx_ioctl */, &arg1); arg2.in.handle = 0x0; arg2.in.timeout = 0x2000000000000; arg2.in.ip_type = AMD_IP_VPE /* 0x9 */; arg2->in.ip_instance = 0x0; arg2.in.ring = 0x0; arg2.in.ctx_id = arg1.out.alloc.ctx_id; drmIoctl(fd, 0xc0206449 /* AMDGPU_WAIT_CS * /, &arg2); } The ioctl AMDGPU_WAIT_CS without previously submitted job could be assumed that the error should be returned, but the following commit 1decbf6bb0b4dc56c9da6c5e57b994ebfc2be3aa modified the logic and allowed to have sched_rq equal to NULL. As a result when there is no job the ioctl AMDGPU_WAIT_CS returns success. The change fixes null-ptr-deref in init entity and the stack below demonstrates the error condition: [ +0.000007] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ +0.007086] #PF: supervisor read access in kernel mode [ +0.005234] #PF: error_code(0x0000) – not-present page [ +0.005232] PGD 0 P4D 0 [ +0.002501] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ +0.005034] CPU: 10 PID: 9229 Comm: amd_basic Tainted: G B W L 6.7.0+ #4 [ +0.007797] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.009798] RIP: 0010:drm_sched_entity_init+0x2d3/0x420 [gpu_sched] [ +0.006426] Code: 80 00 00 00 00 00 00 00 e8 1a 81 82 e0 49 89 9c 24 c0 00 00 00 4c 89 ef e8 4a 80 82 e0 49 8b 5d 00 48 8d 7b 28 e8 3d 80 82 e0 <48> 83 7b 28 00 0f 84 28 01 00 00 4d 8d ac 24 98 00 00 00 49 8d 5c [ +0.019094] RSP: 0018:ffffc90014c1fa40 EFLAGS: 00010282 [ +0.005237] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff8113f3fa [ +0.007326] RDX: fffffbfff0a7889d RSI: 0000000000000008 RDI: ffffffff853c44e0 [ +0.007264] RBP: ffffc90014c1fa80 R08: 0000000000000001 R09: fffffbfff0a7889c [ +0.007266] R10: ffffffff853c44e7 R11: 0000000000000001 R12: ffff8881a719b010 [ +0.007263] R13: ffff88810d412748 R14: 0000000000000002 R15: 0000000000000000 [ +0.007264] FS: 00007ffff7045540(0000) GS:ffff8883cc900000(0000) knlGS:0000000000000000 [ +0.008236] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.005851] CR2: 0000000000000028 CR3: 000000011912e000 CR4: 0000000000350ef0 [ +0.007175] Call Trace: [ +0.002561] <TASK> [ +0.002141] ? show_regs+0x6a/0x80 [ +0.003473] ? __die+0x25/0x70 [ +0.003124] ? page_fault_oops+0x214/0x720 [ +0.004179] ? preempt_count_sub+0x18/0xc0 [ +0.004093] ? __pfx_page_fault_oops+0x10/0x10 [ +0.004590] ? srso_return_thunk+0x5/0x5f [ +0.004000] ? vprintk_default+0x1d/0x30 [ +0.004063] ? srso_return_thunk+0x5/0x5f [ +0.004087] ? vprintk+0x5c/0x90 [ +0.003296] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched] [ +0.005807] ? srso_return_thunk+0x5/0x5f [ +0.004090] ? _printk+0xb3/0xe0 [ +0.003293] ? __pfx__printk+0x10/0x10 [ +0.003735] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ +0.005482] ? do_user_addr_fault+0x345/0x770 [ +0.004361] ? exc_page_fault+0x64/0xf0 [ +0.003972] ? asm_exc_page_fault+0x27/0x30 [ +0.004271] ? add_taint+0x2a/0xa0 [ +0.003476] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched] [ +0.005812] amdgpu_ctx_get_entity+0x3f9/0x770 [amdgpu] [ +0.009530] ? finish_task_switch.isra.0+0x129/0x470 [ +0.005068] ? __pfx_amdgpu_ctx_get_entity+0x10/0x10 [amdgpu] [ +0.010063] ? __kasan_check_write+0x14/0x20 [ +0.004356] ? srso_return_thunk+0x5/0x5f [ +0.004001] ? mutex_unlock+0x81/0xd0 [ +0.003802] ? srso_return_thunk+0x5/0x5f [ +0.004096] amdgpu_cs_wait_ioctl+0xf6/0x270 [amdgpu] [ +0.009355] ? __pfx_ —truncated— 2024-04-02 not yet calculated CVE-2024-26657
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: bcachefs: grab s_umount only if snapshotting When I was testing mongodb over bcachefs with compression, there is a lockdep warning when snapshotting mongodb data volume. $ cat test.sh prog=bcachefs $prog subvolume create /mnt/data $prog subvolume create /mnt/data/snapshots while true;do $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s) sleep 1s done $ cat /etc/mongodb.conf systemLog: destination: file logAppend: true path: /mnt/data/mongod.log storage: dbPath: /mnt/data/ lockdep reports: [ 3437.452330] ====================================================== [ 3437.452750] WARNING: possible circular locking dependency detected [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E [ 3437.453562] —————————————————— [ 3437.453981] bcachefs/35533 is trying to acquire lock: [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190 [ 3437.454875] but task is already holding lock: [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.456009] which lock already depends on the new lock. [ 3437.456553] the existing dependency chain (in reverse order) is: [ 3437.457054] -> #3 (&type->s_umount_key#48){.+.+}-{3:3}: [ 3437.457507] down_read+0x3e/0x170 [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.458206] __x64_sys_ioctl+0x93/0xd0 [ 3437.458498] do_syscall_64+0x42/0xf0 [ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.459155] -> #2 (&c->snapshot_create_lock){++++}-{3:3}: [ 3437.459615] down_read+0x3e/0x170 [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs] [ 3437.460686] notify_change+0x1f1/0x4a0 [ 3437.461283] do_truncate+0x7f/0xd0 [ 3437.461555] path_openat+0xa57/0xce0 [ 3437.461836] do_filp_open+0xb4/0x160 [ 3437.462116] do_sys_openat2+0x91/0xc0 [ 3437.462402] __x64_sys_openat+0x53/0xa0 [ 3437.462701] do_syscall_64+0x42/0xf0 [ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}: [ 3437.463843] down_write+0x3b/0xc0 [ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs] [ 3437.464493] vfs_write+0x21b/0x4c0 [ 3437.464653] ksys_write+0x69/0xf0 [ 3437.464839] do_syscall_64+0x42/0xf0 [ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.465231] -> #0 (sb_writers#10){.+.+}-{0:0}: [ 3437.465471] __lock_acquire+0x1455/0x21b0 [ 3437.465656] lock_acquire+0xc6/0x2b0 [ 3437.465822] mnt_want_write+0x46/0x1a0 [ 3437.465996] filename_create+0x62/0x190 [ 3437.466175] user_path_create+0x2d/0x50 [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] __x64_sys_ioctl+0x93/0xd0 [ 3437.466791] do_syscall_64+0x42/0xf0 [ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.467180] other info that might help us debug this: [ 3437.469670] 2 locks held by bcachefs/35533: other info that might help us debug this: [ 3437.467507] Chain exists of: sb_writers#10 –> &c->snapshot_create_lock –> &type->s_umount_key#48 [ 3437.467979] Possible unsafe locking scenario: [ 3437.468223] CPU0 CPU1 [ 3437.468405] —- —- [ 3437.468585] rlock(&type->s_umount_key#48); [ 3437.468758] lock(&c->snapshot_create_lock); [ 3437.469030] lock(&type->s_umount_key#48); [ 3437.469291] rlock(sb_writers#10); [ 3437.469434] *** DEADLOCK *** [ 3437.469 —truncated— 2024-04-02 not yet calculated CVE-2024-26658
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in “Transfer event TRB DMA ptr not part of current TD” error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled. 2024-04-02 not yet calculated CVE-2024-26659
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: Implement bounds check for stream encoder creation in DCN301 ‘stream_enc_regs’ array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message ‘stream_enc_regs’ 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn301_stream_encoder_create reported by Smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow ‘stream_enc_regs’ 4 <= 5 2024-04-02 not yet calculated CVE-2024-26660
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 test for ‘timing generator’ in ‘dcn21_set_pipe()’ In “u32 otg_inst = pipe_ctx->stream_res.tg->inst;” pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to ensure the tg is not NULL. 2024-04-02 not yet calculated CVE-2024-26661
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 ‘panel_cntl’ could be null in ‘dcn21_set_backlight_level()’ ‘panel_cntl’ structure used to control the display panel could be null, dereferencing it could lead to a null pointer access. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed ‘panel_cntl’ could be null (see line 250) 2024-04-02 not yet calculated CVE-2024-26662
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: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] … RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 … Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). 2024-04-02 not yet calculated CVE-2024-26663
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: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package. 2024-04-02 not yet calculated CVE-2024-26664
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: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 … kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs. 2024-04-02 not yet calculated CVE-2024-26665
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: fix RCU use in TDLS fast-xmit This looks up the link under RCU protection, but isn’t guaranteed to actually have protection. Fix that. 2024-04-02 not yet calculated CVE-2024-26666
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/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 (“drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output”) introduced a smatch warning about another conditional block in dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it. Patchwork: https://patchwork.freedesktop.org/patch/574878/ 2024-04-02 not yet calculated CVE-2024-26667
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: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit. 2024-04-02 not yet calculated CVE-2024-26668
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/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the ‘FLOW_BLOCK_UNBIND’ command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the ‘reoffload’ operation of the classifier being used. In turn, the classifier in its ‘reoffload’ operation prepares and emits a ‘FLOW_CLS_DESTROY’ command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a ‘FLOW_CLS_TMPLT_DESTROY’ command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a ‘tmplt_reoffload’ operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the ‘FLOW_CLS_TMPLT_{CREATE,DESTROY}’ command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm “tc”, pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|……[…… 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ……………. backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab374e>] __kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm “tc”, pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @…….W.8….. 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m……,m…. backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90 [<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0 [<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460 [<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0 [<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev —truncated— 2024-04-02 not yet calculated CVE-2024-26669
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: arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD Currently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn’t quite right, as it is supposed to be applied after the last explicit memory access, but is immediately followed by an LDR. The ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to handle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295, which are described in: * https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en * https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en In both cases the workaround is described as: | If pagetable isolation is disabled, the context switch logic in the | kernel can be updated to execute the following sequence on affected | cores before exiting to EL0, and after all explicit memory accesses: | | 1. A non-shareable TLBI to any context and/or address, including | unused contexts or addresses, such as a `TLBI VALE1 Xzr`. | | 2. A DSB NSH to guarantee completion of the TLBI. The important part being that the TLBI+DSB must be placed “after all explicit memory accesses”. Unfortunately, as-implemented, the TLBI+DSB is immediately followed by an LDR, as we have: | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh | alternative_else_nop_endif | alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0 | ldr lr, [sp, #S_LR] | add sp, sp, #PT_REGS_SIZE // restore sp | eret | alternative_else_nop_endif | | [ … KPTI exception return path … ] This patch fixes this by reworking the logic to place the TLBI+DSB immediately before the ERET, after all explicit memory accesses. The ERET is currently in a separate alternative block, and alternatives cannot be nested. To account for this, the alternative block for ARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branch to skip the KPTI logic, with the new shape of the logic being: | alternative_insn “b .L_skip_tramp_exit_@”, nop, ARM64_UNMAP_KERNEL_AT_EL0 | [ … KPTI exception return path … ] | .L_skip_tramp_exit_@: | | ldr lr, [sp, #S_LR] | add sp, sp, #PT_REGS_SIZE // restore sp | | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh | alternative_else_nop_endif | eret The new structure means that the workaround is only applied when KPTI is not in use; this is fine as noted in the documented implications of the erratum: | Pagetable isolation between EL0 and higher level ELs prevents the | issue from occurring. … and as per the workaround description quoted above, the workaround is only necessary “If pagetable isolation is disabled”. 2024-04-02 not yet calculated CVE-2024-26670
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: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can’t get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio –filename=/dev/”$dev” –direct=1 –rw=randrw –bs=4k –iodepth=1 –runtime=100 –numjobs=40 –time_based –name=test –ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. 2024-04-02 not yet calculated CVE-2024-26671
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/amdgpu: Fix variable ‘mca_funcs’ dereferenced before NULL check in ‘amdgpu_mca_smu_get_mca_entry()’ Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check ‘mca_funcs’ (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late! 2024-04-02 not yet calculated CVE-2024-26672
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations – Disallow families other than NFPROTO_{IPV4,IPV6,INET}. – Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object. 2024-04-02 not yet calculated CVE-2024-26673
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: x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups During memory error injection test on kernels >= v6.4, the kernel panics like below. However, this issue couldn’t be reproduced on kernels <= v6.3. mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134 mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20} mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86 mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490 mce: [Hardware Error]: Run the above through ‘mcelog –ascii’ mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic – not syncing: Fatal local machine check The MCA code can recover from an in-kernel #MC if the fixup type is EX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to access userspace memory. However, if the fixup type is EX_TYPE_DEFAULT the only thing that is raised for an in-kernel #MC is a panic. ex_handler_uaccess() would warn if users gave a non-canonical addresses (with bit 63 clear) to {get, put}_user(), which was unexpected. Therefore, commit b19b74bc99b1 (“x86/mm: Rework address range check in get_user() and put_user()”) replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user() fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic. Commit 6014bc27561f (“x86-64: make access_ok() independent of LAM”) added the check gp_fault_address_ok() right before the WARN_ONCE() in ex_handler_uaccess() to not warn about non-canonical user addresses due to LAM. With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user() exception fixups in order to be able to handle in-kernel MCEs correctly again. [ bp: Massage commit message. ] 2024-04-02 not yet calculated CVE-2024-26674
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: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 (“ppp: limit MRU to 64K”) Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 2024-04-02 not yet calculated CVE-2024-26675
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: af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. syzbot reported a warning [0] in __unix_gc() with a repro, which creates a socketpair and sends one socket’s fd to itself using the peer. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=”360″, iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 This forms a self-cyclic reference that GC should finally untangle but does not due to lack of MSG_OOB handling, resulting in memory leak. Recently, commit 11498715f266 (“af_unix: Remove io_uring code for GC.”) removed io_uring’s dead code in GC and revealed the problem. The code was executed at the final stage of GC and unconditionally moved all GC candidates from gc_candidates to gc_inflight_list. That papered over the reported problem by always making the following WARN_ON_ONCE(!list_empty(&gc_candidates)) false. The problem has been there since commit 2aab4b969002 (“af_unix: fix struct pid leaks in OOB support”) added full scm support for MSG_OOB while fixing another bug. To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb if the socket still exists in gc_candidates after purging collected skb. Then, we need to set NULL to oob_skb before calling kfree_skb() because it calls last fput() and triggers unix_release_sock(), where we call duplicate kfree_skb(u->oob_skb) if not NULL. Note that the leaked socket remained being linked to a global list, so kmemleak also could not detect it. We need to check /proc/net/protocol to notice the unfreed socket. [0]: WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Modules linked in: CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: events_unbound __unix_gc RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8 RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30 RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66 R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000 R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> process_one_work+0x889/0x15e0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> 2024-04-02 not yet calculated CVE-2024-26676
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: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can’t be used as an RTT reference. 2024-04-02 not yet calculated CVE-2024-26677
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/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section The .compat section is a dummy PE section that contains the address of the 32-bit entrypoint of the 64-bit kernel image if it is bootable from 32-bit firmware (i.e., CONFIG_EFI_MIXED=y) This section is only 8 bytes in size and is only referenced from the loader, and so it is placed at the end of the memory view of the image, to avoid the need for padding it to 4k, which is required for sections appearing in the middle of the image. Unfortunately, this violates the PE/COFF spec, and even if most EFI loaders will work correctly (including the Tianocore reference implementation), PE loaders do exist that reject such images, on the basis that both the file and memory views of the file contents should be described by the section headers in a monotonically increasing manner without leaving any gaps. So reorganize the sections to avoid this issue. This results in a slight padding overhead (< 4k) which can be avoided if desired by disabling CONFIG_EFI_MIXED (which is only needed in rare cases these days) 2024-04-02 not yet calculated CVE-2024-26678
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: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. 2024-04-02 not yet calculated CVE-2024-26679
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: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ————[ cut here ]———— [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 … [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] … [ 216.127540] —[ end trace 6467e5964dd2640b ]— [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic] 2024-04-02 not yet calculated CVE-2024-26680
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: netdevsim: avoid potential loop in nsim_dev_trap_report_work() Many syzbot reports include the following trace [1] If nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1] Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> instrument_atomic_read include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> 2024-04-02 not yet calculated CVE-2024-26681
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: improve CSA/ECSA connection refusal As mentioned in the previous commit, we pretty quickly found that some APs have ECSA elements stuck in their probe response, so using that to not attempt to connect while CSA is happening we never connect to such an AP. Improve this situation by checking more carefully and ignoring the ECSA if cfg80211 has previously detected the ECSA element being stuck in the probe response. Additionally, allow connecting to an AP that’s switching to a channel it’s already using, unless it’s using quiet mode. In this case, we may just have to adjust bandwidth later. If it’s actually switching channels, it’s better not to try to connect in the middle of that. 2024-04-02 not yet calculated CVE-2024-26682
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: detect stuck ECSA element in probe resp We recently added some validation that we don’t try to connect to an AP that is currently in a channel switch process, since that might want the channel to be quiet or we might not be able to connect in time to hear the switching in a beacon. This was in commit c09c4f31998b (“wifi: mac80211: don’t connect to an AP while it’s in a CSA process”). However, we promptly got a report that this caused new connection failures, and it turns out that the AP that we now cannot connect to is permanently advertising an extended channel switch announcement, even with quiet. The AP in question was an Asus RT-AC53, with firmware 3.0.0.4.380_10760-g21a5898. As a first step, attempt to detect that we’re dealing with such a situation, so mac80211 can use this later. 2024-04-02 not yet calculated CVE-2024-26683
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 (“net: stmmac: Implement Safety Features in XGMAC core”) checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. 2024-04-02 not yet calculated CVE-2024-26684
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 potential bug in end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 (“nilfs2: fix issue with race condition of competition between segments for dirty blocks”) as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel. The use of async_write for segment summary buffers has already been removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer. 2024-04-03 not yet calculated CVE-2024-26685
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/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless. 2024-04-03 not yet calculated CVE-2024-26686
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: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can’t due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: – shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). – __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn’t take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it’s potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 (“xen/events: modify internal [un]bind interfaces”), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it’s therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ————[ cut here ]———— blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x —truncated— 2024-04-03 not yet calculated CVE-2024-26687
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,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfs_fill_super() caused by assigning NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize is non valid. E.g: Taking the following steps: fd = fsopen(“hugetlbfs”, FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, “pagesize”, “1024”, 0); fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); Given that the requested “pagesize” is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error: … … case Opt_pagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { pr_err(“Unsupported page size %lu MBn”, ps / SZ_1M); return -EINVAL; } return 0; … … This is a problem because later on, we will dereference ctxt->hstate in hugetlbfs_fill_super() … … sb->s_blocksize = huge_page_size(ctx->hstate); … … Causing below Oops. Fix this by replacing cxt->hstate value only when then pagesize is known to be valid. kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) – not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel: <TASK> kernel: ? __die_body+0x1a/0x60 kernel: ? page_fault_oops+0x16f/0x4a0 kernel: ? search_bpf_extables+0x65/0x70 kernel: ? fixup_exception+0x22/0x310 kernel: ? exc_page_fault+0x69/0x150 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: ? hugetlbfs_fill_super+0xb4/0x1a0 kernel: ? hugetlbfs_fill_super+0x28/0x1a0 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: vfs_get_super+0x40/0xa0 kernel: ? __pfx_bpf_lsm_capable+0x10/0x10 kernel: vfs_get_tree+0x25/0xd0 kernel: vfs_cmd_create+0x64/0xe0 kernel: __x64_sys_fsconfig+0x395/0x410 kernel: do_syscall_64+0x80/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? exc_page_fault+0x69/0x150 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff —truncated— 2024-04-03 not yet calculated CVE-2024-26688
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: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), “use after free” error was caught by KASAN at this line – ‘ceph_buffer_get(arg->xattr_buf);’. This implies before the refcount could be increment here, it was freed. In same file, in “handle_cap_grant()” refcount is decremented by this line – ‘ceph_buffer_put(ci->i_xattrs.blob);’. It appears that a race occurred and resource was freed by the latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent “use after free” error. 2024-04-03 not yet calculated CVE-2024-26689
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: stmmac: protect updates of 64-bit statistics counters As explained by a comment in <linux/u64_stats_sync.h>, write side of struct u64_stats_sync must ensure mutual exclusion, or one seqcount update could be lost on 32-bit platforms, thus blocking readers forever. Such lockups have been observed in real world after stmmac_xmit() on one CPU raced with stmmac_napi_poll_tx() on another CPU. To fix the issue without introducing a new lock, split the statics into three parts: 1. fields updated only under the tx queue lock, 2. fields updated only during NAPI poll, 3. fields updated only from interrupt context, Updates to fields in the first two groups are already serialized through other locks. It is sufficient to split the existing struct u64_stats_sync so that each group has its own. Note that tx_set_ic_bit is updated from both contexts. Split this counter so that each context gets its own, and calculate their sum to get the total value in stmmac_get_ethtool_stats(). For the third group, multiple interrupts may be processed by different CPUs at the same time, but interrupts on the same CPU will not nest. Move fields from this group to a newly created per-cpu struct stmmac_pcpu_stats. 2024-04-03 not yet calculated CVE-2024-26690
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: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data. 2024-04-03 not yet calculated CVE-2024-26691
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: smb: Fix regression in writes when non-standard maximum write size negotiated The conversion to netfs in the 6.3 kernel caused a regression when maximum write size is set by the server to an unexpected value which is not a multiple of 4096 (similarly if the user overrides the maximum write size by setting mount parm “wsize”, but sets it to a value that is not a multiple of 4096). When negotiated write size is not a multiple of 4096 the netfs code can skip the end of the final page when doing large sequential writes, causing data corruption. This section of code is being rewritten/removed due to a large netfs change, but until that point (ie for the 6.3 kernel until now) we can not support non-standard maximum write sizes. Add a warning if a user specifies a wsize on mount that is not a multiple of 4096 (and round down), also add a change where we round down the maximum write size if the server negotiates a value that is not a multiple of 4096 (we also have to check to make sure that we do not round it down to zero). 2024-04-03 not yet calculated CVE-2024-26692
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: iwlwifi: mvm: fix a crash when we run out of stations A DoS tool that injects loads of authentication frames made our AP crash. The iwl_mvm_is_dup() function couldn’t find the per-queue dup_data which was not allocated. The root cause for that is that we ran out of stations in the firmware and we didn’t really add the station to the firmware, yet we didn’t return an error to mac80211. Mac80211 was thinking that we have the station and because of that, sta_info::uploaded was set to 1. This allowed ieee80211_find_sta_by_ifaddr() to return a valid station object, but that ieee80211_sta didn’t have any iwl_mvm_sta object initialized and that caused the crash mentioned earlier when we got Rx on that station. 2024-04-03 not yet calculated CVE-2024-26693
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: iwlwifi: fix double-free bug The storage for the TLV PC register data wasn’t done like all the other storage in the drv->fw area, which is cleared at the end of deallocation. Therefore, the freeing must also be done differently, explicitly NULL’ing it out after the free, since otherwise there’s a nasty double-free bug here if a file fails to load after this has been parsed, and we get another free later (e.g. because no other file exists.) Fix that by adding the missing NULL assignment. 2024-04-03 not yet calculated CVE-2024-26694
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: ccp – Fix null pointer dereference in __sev_platform_shutdown_locked The SEV platform device can be shutdown with a null psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [ 137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [ 137.182693] ? asm_exc_general_protection+0x2b/0x30 [ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693] really_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.182693] ? __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10 [ 137.182693] ? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_register_driver+0x1d6/0x2a0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [ 137.182693] ? parameq+0x80/0xf0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] kernel_init_freeable+0xa64/0x1050 [ 137.182693] ? __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 —truncated— 2024-04-03 not yet calculated CVE-2024-26695
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 hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device. 2024-04-03 not yet calculated CVE-2024-26696
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 data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file’s page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page. 2024-04-03 not yet calculated CVE-2024-26697
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: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove In commit ac5047671758 (“hv_netvsc: Disable NAPI before closing the VMBus channel”), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not. This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run. netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the opposite. Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep. This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose. Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] <TASK> [ 654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus] 2024-04-03 not yet calculated CVE-2024-26698
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: Fix array-index-out-of-bounds in dcn35_clkmgr [Why] There is a potential memory access violation while iterating through array of dcn35 clks. [How] Limit iteration per array size. 2024-04-03 not yet calculated CVE-2024-26699
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 MST Null Ptr for RV The change try to fix below error specific to RV platform: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 ? _copy_to_user+0x25/0x30 ? drm_ioctl+0x296/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xcd/0x170 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4dad17f76f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0 </TASK> Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep > typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas> CR2: 0000000000000008 —[ end trace 0000000000000000 ]— RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000 —truncated— 2024-04-03 not yet calculated CVE-2024-26700
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: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC Recently, we encounter kernel crash in function rm3100_common_probe caused by out of bound access of array rm3100_samp_rates (because of underlying hardware failures). Add boundary check to prevent out of bound access. 2024-04-03 not yet calculated CVE-2024-26702
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: tracing/timerlat: Move hrtimer_init to timerlat_fd open() Currently, the timerlat’s hrtimer is initialized at the first read of timerlat_fd, and destroyed at close(). It works, but it causes an error if the user program open() and close() the file without reading. Here’s an example: # echo NO_OSNOISE_WORKLOAD > /sys/kernel/debug/tracing/osnoise/options # echo timerlat > /sys/kernel/debug/tracing/current_tracer # cat <<EOF > ./timerlat_load.py # !/usr/bin/env python3 timerlat_fd = open(“/sys/kernel/tracing/osnoise/per_cpu/cpu0/timerlat_fd”, ‘r’) timerlat_fd.close(); EOF # ./taskset -c 0 ./timerlat_load.py <BOOM> BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) – not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2673 Comm: python3 Not tainted 6.6.13-200.fc39.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:hrtimer_active+0xd/0x50 Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 57 30 <8b> 42 10 a8 01 74 09 f3 90 8b 42 10 a8 01 75 f7 80 7f 38 00 75 1d RSP: 0018:ffffb031009b7e10 EFLAGS: 00010286 RAX: 000000000002db00 RBX: ffff9118f786db08 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9117a0e64400 RDI: ffff9118f786db08 RBP: ffff9118f786db80 R08: ffff9117a0ddd420 R09: ffff9117804d4f70 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9118f786db08 R13: ffff91178fdd5e20 R14: ffff9117840978c0 R15: 0000000000000000 FS: 00007f2ffbab1740(0000) GS:ffff9118f7840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 00000001b402e000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? srso_alias_return_thunk+0x5/0x7f ? avc_has_extended_perms+0x237/0x520 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? hrtimer_active+0xd/0x50 hrtimer_cancel+0x15/0x40 timerlat_fd_release+0x48/0xe0 __fput+0xf5/0x290 __x64_sys_close+0x3d/0x80 do_syscall_64+0x60/0x90 ? srso_alias_return_thunk+0x5/0x7f ? __x64_sys_ioctl+0x72/0xd0 ? srso_alias_return_thunk+0x5/0x7f ? syscall_exit_to_user_mode+0x2b/0x40 ? srso_alias_return_thunk+0x5/0x7f ? do_syscall_64+0x6c/0x90 ? srso_alias_return_thunk+0x5/0x7f ? exit_to_user_mode_prepare+0x142/0x1f0 ? srso_alias_return_thunk+0x5/0x7f ? syscall_exit_to_user_mode+0x2b/0x40 ? srso_alias_return_thunk+0x5/0x7f ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f2ffb321594 Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 cd 0d 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 7d RSP: 002b:00007ffe8d8eef18 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 00007f2ffba4e668 RCX: 00007f2ffb321594 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffe8d8eef40 R08: 0000000000000000 R09: 0000000000000000 R10: 55c926e3167eae79 R11: 0000000000000202 R12: 0000000000000003 R13: 00007ffe8d8ef030 R14: 0000000000000000 R15: 00007f2ffba4e668 </TASK> CR2: 0000000000000010 —[ end trace 0000000000000000 ]— Move hrtimer_init to timerlat_fd open() to avoid this problem. 2024-04-03 not yet calculated CVE-2024-26703
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: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd (“ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT”)), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue. 2024-04-03 not yet calculated CVE-2024-26704
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: parisc: BTLB: Fix crash when setting up BTLB at CPU bringup When using hotplug and bringing up a 32-bit CPU, ask the firmware about the BTLB information to set up the static (block) TLB entries. For that write access to the static btlb_info struct is needed, but since it is marked __ro_after_init the kernel segfaults with missing write permissions. Fix the crash by dropping the __ro_after_init annotation. 2024-04-03 not yet calculated CVE-2024-26705
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: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the “%r” prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction “or %r0,%r0,%reg”, where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can’t use the BUILDTIME_TABLE_SORT config option any longer. 2024-04-03 not yet calculated CVE-2024-26706
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: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will not help much in this case, it might be prudent to switch to netdev_warn_once(). At the very least it will suppress syzkaller reports such as [1]. Just in case, use netdev_warn_once() in send_prp_supervision_frame() for similar reasons. [1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 … Call Trace: <IRQ> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 … This issue is also found in older kernels (at least up to 5.10). 2024-04-03 not yet calculated CVE-2024-26707
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: mptcp: really cope with fastopen race Fastopen and PM-trigger subflow shutdown can race, as reported by syzkaller. In my first attempt to close such race, I missed the fact that the subflow status can change again before the subflow_state_change callback is invoked. Address the issue additionally copying with all the states directly reachable from TCP_FIN_WAIT1. 2024-04-03 not yet calculated CVE-2024-26708
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/iommu: Fix the missing iommu_group_put() during platform domain attach The function spapr_tce_platform_iommu_attach_dev() is missing to call iommu_group_put() when the domain is already set. This refcount leak shows up with BUG_ON() during DLPAR remove operation as: KernelBug: Kernel bug in state ‘None’: kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries <snip> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_016) hv:phyp pSeries NIP: c0000000000ff4d4 LR: c0000000000ff4cc CTR: 0000000000000000 REGS: c0000013aed5f840 TRAP: 0700 Tainted: G I (6.8.0-rc3-autotest-g99bd3cb0d12e) MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 44002402 XER: 20040000 CFAR: c000000000a0d170 IRQMASK: 0 … NIP iommu_reconfig_notifier+0x94/0x200 LR iommu_reconfig_notifier+0x8c/0x200 Call Trace: iommu_reconfig_notifier+0x8c/0x200 (unreliable) notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 of_reconfig_notify+0x44/0xdc of_detach_node+0x78/0xb0 ofdt_write.part.0+0x86c/0xbb8 proc_reg_write+0xf4/0x150 vfs_write+0xf8/0x488 ksys_write+0x84/0x140 system_call_exception+0x138/0x330 system_call_vectored_common+0x15c/0x2ec The patch adds the missing iommu_group_put() call. 2024-04-03 not yet calculated CVE-2024-26709
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Limit KASAN thread size increase to 32KB KASAN is seen to increase stack usage, to the point that it was reported to lead to stack overflow on some 32-bit machines (see link). To avoid overflows the stack size was doubled for KASAN builds in commit 3e8635fb2e07 (“powerpc/kasan: Force thread size increase with KASAN”). However with a 32KB stack size to begin with, the doubling leads to a 64KB stack, which causes build errors: arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff) Although the asm could be reworked, in practice a 32KB stack seems sufficient even for KASAN builds – the additional usage seems to be in the 2-3KB range for a 64-bit KASAN build. So only increase the stack for KASAN if the stack size is < 32KB. 2024-04-03 not yet calculated CVE-2024-26710
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: adc: ad4130: zero-initialize clock init data The clk_init_data struct does not have all its members initialized, causing issues when trying to expose the internal clock on the CLK pin. Fix this by zero-initializing the clk_init_data struct. 2024-04-03 not yet calculated CVE-2024-26711
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/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur – k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { […] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end – k_start, PAGE_SIZE); […] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur – k_start; […] } […] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address. 2024-04-03 not yet calculated CVE-2024-26712
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/iommu: Fix iommu initialisation during DLPAR add When a PCI device is dynamically added, the kernel oopses with a NULL pointer dereference: BUG: Kernel NULL pointer dereference on read at 0x00000030 Faulting instruction address: 0xc0000000006bbe5c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24002220 XER: 20040006 CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0 … NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Call Trace: iommu_init_device+0x26c/0x318 (unreliable) iommu_device_link+0x5c/0x118 iommu_init_device+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+0x44/0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_scan_pci_dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+0xb8/0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec Commit a940904443e4 (“powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains”) broke DLPAR add of PCI devices. The above added iommu_device structure to pci_controller. During system boot, PCI devices are discovered and this newly added iommu_device structure is initialized by a call to iommu_device_register(). During DLPAR add of a PCI device, a new pci_controller structure is allocated but there are no calls made to iommu_device_register() interface. Fix is to register the iommu device during DLPAR add as well. [mpe: Trim oops and tweak some change log wording] 2024-04-03 not yet calculated CVE-2024-26713
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: interconnect: qcom: sc8180x: Mark CO0 BCM keepalive The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases. 2024-04-03 not yet calculated CVE-2024-26714
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: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. 2024-04-03 not yet calculated CVE-2024-26715
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: Prevent null pointer dereference in update_port_device_state Currently, the function update_port_device_state gets the usb_hub from udev->parent by calling usb_hub_to_struct_hub. However, in case the actconfig or the maxchild is 0, the usb_hub would be NULL and upon further accessing to get port_dev would result in null pointer dereference. Fix this by introducing an if check after the usb_hub is populated. 2024-04-03 not yet calculated CVE-2024-26716
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: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures. 2024-04-03 not yet calculated CVE-2024-26717
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: dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet callback frees the structure that contains the tasklet or if it calls some code that may free it, tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer from the memory corruption problem. But we need something that stops the memory corruption now and that can be backported to the stable kernels. So, I’m proposing this commit that disables tasklets in both dm-crypt and dm-verity. This commit doesn’t remove the tasklet support, because the tasklet code will be reused when atomic workqueues will be implemented. [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/ [2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/ 2024-04-03 not yet calculated CVE-2024-26718
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: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. 2024-04-03 not yet calculated CVE-2024-26719
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/writeback: fix possible divide-by-zero in wb_dirty_limits(), again (struct dirty_throttle_control *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated. Use div64_u64() instead of div_u64() so that the value used in the “is this a safe division” check is the same as the divisor. Also, remove redundant cast of the numerator to u64, as that should happen implicitly. This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domain_drity_limits() uses, but is much easier in global writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) 2024-04-03 not yet calculated CVE-2024-26720
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/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address Commit bd077259d0a9 (“drm/i915/vdsc: Add function to read any PPS register”) defines a new macro to calculate the DSC PPS register addresses with PPS number as an input. This macro correctly calculates the addresses till PPS 11 since the addresses increment by 4. So in that case the following macro works correctly to give correct register address: _MMIO(_DSCA_PPS_0 + (pps) * 4) However after PPS 11, the register address for PPS 12 increments by 12 because of RC Buffer memory allocation in between. Because of this discontinuity in the address space, the macro calculates wrong addresses for PPS 12 – 16 resulting into incorrect DSC PPS parameter value read/writes causing DSC corruption. This fixes it by correcting this macro to add the offset of 12 for PPS >=12. v3: Add correct paranthesis for pps argument (Jani Nikula) (cherry picked from commit 6074be620c31dc2ae11af96a1a5ea95580976fb5) 2024-04-03 not yet calculated CVE-2024-26721
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time. Found by Linux Verification Center (linuxtesting.org) with SVACE. 2024-04-03 not yet calculated CVE-2024-26722
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: lan966x: Fix crash when adding interface under a lag There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0 The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places. 2024-04-03 not yet calculated CVE-2024-26723
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/mlx5: DPLL, Fix possible use after free after delayed work timer triggers I managed to hit following use after free warning recently: [ 2169.711665] ================================================================== [ 2169.714009] BUG: KASAN: slab-use-after-free in __run_timers.part.0+0x179/0x4c0 [ 2169.716293] Write of size 8 at addr ffff88812b326a70 by task swapper/4/0 [ 2169.719022] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.8.0-rc2jiri+ #2 [ 2169.720974] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 2169.722457] Call Trace: [ 2169.722756] <IRQ> [ 2169.723024] dump_stack_lvl+0x58/0xb0 [ 2169.723417] print_report+0xc5/0x630 [ 2169.723807] ? __virt_addr_valid+0x126/0x2b0 [ 2169.724268] kasan_report+0xbe/0xf0 [ 2169.724667] ? __run_timers.part.0+0x179/0x4c0 [ 2169.725116] ? __run_timers.part.0+0x179/0x4c0 [ 2169.725570] __run_timers.part.0+0x179/0x4c0 [ 2169.726003] ? call_timer_fn+0x320/0x320 [ 2169.726404] ? lock_downgrade+0x3a0/0x3a0 [ 2169.726820] ? kvm_clock_get_cycles+0x14/0x20 [ 2169.727257] ? ktime_get+0x92/0x150 [ 2169.727630] ? lapic_next_deadline+0x35/0x60 [ 2169.728069] run_timer_softirq+0x40/0x80 [ 2169.728475] __do_softirq+0x1a1/0x509 [ 2169.728866] irq_exit_rcu+0x95/0xc0 [ 2169.729241] sysvec_apic_timer_interrupt+0x6b/0x80 [ 2169.729718] </IRQ> [ 2169.729993] <TASK> [ 2169.730259] asm_sysvec_apic_timer_interrupt+0x16/0x20 [ 2169.730755] RIP: 0010:default_idle+0x13/0x20 [ 2169.731190] Code: c0 08 00 00 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 8b 05 9a 7f 1f 02 85 c0 7e 07 0f 00 2d cf 69 43 00 fb f4 <fa> c3 66 66 2e 0f 1f 84 00 00 00 00 00 65 48 8b 04 25 c0 93 04 00 [ 2169.732759] RSP: 0018:ffff888100dbfe10 EFLAGS: 00000242 [ 2169.733264] RAX: 0000000000000001 RBX: ffff888100d9c200 RCX: ffffffff8241bd62 [ 2169.733925] RDX: ffffed109a848b15 RSI: 0000000000000004 RDI: ffffffff8127ac55 [ 2169.734566] RBP: 0000000000000004 R08: 0000000000000000 R09: ffffed109a848b14 [ 2169.735200] R10: ffff8884d42458a3 R11: 000000000000ba7e R12: ffffffff83d7d3a0 [ 2169.735835] R13: 1ffff110201b7fc6 R14: 0000000000000000 R15: ffff888100d9c200 [ 2169.736478] ? ct_kernel_exit.constprop.0+0xa2/0xc0 [ 2169.736954] ? do_idle+0x285/0x290 [ 2169.737323] default_idle_call+0x63/0x90 [ 2169.737730] do_idle+0x285/0x290 [ 2169.738089] ? arch_cpu_idle_exit+0x30/0x30 [ 2169.738511] ? mark_held_locks+0x1a/0x80 [ 2169.738917] ? lockdep_hardirqs_on_prepare+0x12e/0x200 [ 2169.739417] cpu_startup_entry+0x30/0x40 [ 2169.739825] start_secondary+0x19a/0x1c0 [ 2169.740229] ? set_cpu_sibling_map+0xbd0/0xbd0 [ 2169.740673] secondary_startup_64_no_verify+0x15d/0x16b [ 2169.741179] </TASK> [ 2169.741686] Allocated by task 1098: [ 2169.742058] kasan_save_stack+0x1c/0x40 [ 2169.742456] kasan_save_track+0x10/0x30 [ 2169.742852] __kasan_kmalloc+0x83/0x90 [ 2169.743246] mlx5_dpll_probe+0xf5/0x3c0 [mlx5_dpll] [ 2169.743730] auxiliary_bus_probe+0x62/0xb0 [ 2169.744148] really_probe+0x127/0x590 [ 2169.744534] __driver_probe_device+0xd2/0x200 [ 2169.744973] device_driver_attach+0x6b/0xf0 [ 2169.745402] bind_store+0x90/0xe0 [ 2169.745761] kernfs_fop_write_iter+0x1df/0x2a0 [ 2169.746210] vfs_write+0x41f/0x790 [ 2169.746579] ksys_write+0xc7/0x160 [ 2169.746947] do_syscall_64+0x6f/0x140 [ 2169.747333] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 2169.748049] Freed by task 1220: [ 2169.748393] kasan_save_stack+0x1c/0x40 [ 2169.748789] kasan_save_track+0x10/0x30 [ 2169.749188] kasan_save_free_info+0x3b/0x50 [ 2169.749621] poison_slab_object+0x106/0x180 [ 2169.750044] __kasan_slab_free+0x14/0x50 [ 2169.750451] kfree+0x118/0x330 [ 2169.750792] mlx5_dpll_remove+0xf5/0x110 [mlx5_dpll] [ 2169.751271] auxiliary_bus_remove+0x2e/0x40 [ 2169.751694] device_release_driver_internal+0x24b/0x2e0 [ 2169.752191] unbind_store+0xa6/0xb0 [ 2169.752563] kernfs_fo —truncated— 2024-04-03 not yet calculated CVE-2024-26724
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dpll: fix possible deadlock during netlink dump operation Recently, I’ve been hitting following deadlock warning during dpll pin dump: [52804.637962] ====================================================== [52804.638536] WARNING: possible circular locking dependency detected [52804.639111] 6.8.0-rc2jiri+ #1 Not tainted [52804.639529] —————————————————— [52804.640104] python3/2984 is trying to acquire lock: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}, at: netlink_dump+0xb3/0x780 [52804.641417] but task is already holding lock: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, at: dpll_lock_dumpit+0x13/0x20 [52804.642747] which lock already depends on the new lock. [52804.643551] the existing dependency chain (in reverse order) is: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}: [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578] __netlink_dump_start+0x321/0x450 [52804.647056] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742] __sock_sendmsg+0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.652650] check_prev_add+0x1ae/0x1280 [52804.653107] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984] __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654845] __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg+0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendmsg+0x36d/0x660 [52804.658022] __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184/0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.660281] other info that might help us debug this: [52804.661077] Possible unsafe locking scenario: [52804.661671] CPU0 CPU1 [52804.662129] —- —- [52804.662577] lock(dpll_lock); [52804.662924] lock(nlk_cb_mutex-GENERIC); [52804.663538] lock(dpll_lock); [52804.664073] lock(nlk_cb_mutex-GENERIC); [52804.664490] The issue as follows: __netlink_dump_start() calls control->start(cb) with nlk->cb_mutex held. In control->start(cb) the dpll_lock is taken. Then nlk->cb_mutex is released and taken again in netlink_dump(), while dpll_lock still being held. That leads to ABBA deadlock when another CPU races with the same operation. Fix this by moving dpll_lock taking into dumpit() callback which ensures correct lock taking order. 2024-04-03 not yet calculated CVE-2024-26725
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: don’t drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ————[ cut here ]———— kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we’re deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test. 2024-04-03 not yet calculated CVE-2024-26726
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: do not ASSERT() if the newly created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ————[ cut here ]———— kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b —[ end trace 0000000000000000 ]— [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus we only need to free the preallocated one. 2024-04-03 not yet calculated CVE-2024-26727
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: fix null-pointer dereference on edid reading Use i2c adapter when there isn’t aux_mode in dc_link to fix a null-pointer derefence that happens when running igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector detected as below: [ +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0 [ +0.000010] #PF: supervisor read access in kernel mode [ +0.000005] #PF: error_code(0x0000) – not-present page [ +0.000004] PGD 0 P4D 0 [ +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ #152 [ +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021 [ +0.000004] RIP: 0010:i2c_transfer+0xd/0x100 [ +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16 [ +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246 [ +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080 [ +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0 [ +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980 [ +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080 [ +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f [ +0.000004] FS: 00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0 [ +0.000003] PKRU: 55555554 [ +0.000003] Call Trace: [ +0.000006] <TASK> [ +0.000006] ? __die+0x23/0x70 [ +0.000011] ? page_fault_oops+0x17d/0x4c0 [ +0.000008] ? preempt_count_add+0x6e/0xa0 [ +0.000008] ? srso_alias_return_thunk+0x5/0x7f [ +0.000011] ? exc_page_fault+0x7f/0x180 [ +0.000009] ? asm_exc_page_fault+0x26/0x30 [ +0.000013] ? i2c_transfer+0xd/0x100 [ +0.000010] drm_do_probe_ddc_edid+0xc2/0x140 [drm] [ +0.000067] ? srso_alias_return_thunk+0x5/0x7f [ +0.000006] ? _drm_do_get_edid+0x97/0x3c0 [drm] [ +0.000043] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm] [ +0.000042] edid_block_read+0x3b/0xd0 [drm] [ +0.000043] _drm_do_get_edid+0xb6/0x3c0 [drm] [ +0.000041] ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm] [ +0.000043] drm_edid_read_custom+0x37/0xd0 [drm] [ +0.000044] amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu] [ +0.000153] drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper] [ +0.000000] __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper] [ +0.000000] ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu] [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper] [ +0.000000] status_store+0xb2/0x1f0 [drm] [ +0.000000] kernfs_fop_write_iter+0x136/0x1d0 [ +0.000000] vfs_write+0x24d/0x440 [ +0.000000] ksys_write+0x6f/0xf0 [ +0.000000] do_syscall_64+0x60/0xc0 [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] ? syscall_exit_to_user_mode+0x2b/0x40 [ +0.000000] ? srso_alias_return_thunk+0x5/0x7f [ +0.000000] ? do_syscall_64+0x6c/0xc0 [ +0.000000] ? do_syscall_64+0x6c/0xc0 [ +0.000000] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ +0.000000] RIP: 0033:0x7f9ad46b4b00 [ +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89 [ +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00 [ +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009 [ +0.000000] RBP: 0000000000000002 R08 —truncated— 2024-04-03 not yet calculated CVE-2024-26728
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 potential null pointer dereference in dc_dmub_srv Fixes potential null pointer dereference warnings in the dc_dmub_srv_cmd_list_queue_execute() and dc_dmub_srv_is_hw_pwr_up() functions. In both functions, the ‘dc_dmub_srv’ variable was being dereferenced before it was checked for null. This could lead to a null pointer dereference if ‘dc_dmub_srv’ is null. The fix is to check if ‘dc_dmub_srv’ is null before dereferencing it. Thus moving the null checks for ‘dc_dmub_srv’ to the beginning of the functions to ensure that ‘dc_dmub_srv’ is not null when it is dereferenced. Found by smatch & thus fixing the below: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:133 dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced before check ‘dc_dmub_srv’ (see line 128) drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_is_hw_pwr_up() warn: variable dereferenced before check ‘dc_dmub_srv’ (see line 1164) 2024-04-03 not yet calculated CVE-2024-26729
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775) Fix access to temperature configuration registers The number of temperature configuration registers does not always match the total number of temperature registers. This can result in access errors reported if KASAN is enabled. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core 2024-04-03 not yet calculated CVE-2024-26730
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, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready() syzbot reported the following NULL pointer dereference issue [1]: BUG: kernel NULL pointer dereference, address: 0000000000000000 […] RIP: 0010:0x0 […] Call Trace: <TASK> sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230 unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called concurrently, psock->saved_data_ready can be NULL, causing the above issue. This patch fixes this issue by calling the appropriate data ready function using the sk_psock_data_ready() helper and protecting it from concurrency with sk->sk_callback_lock. 2024-04-03 not yet calculated CVE-2024-26731
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: implement lockless setsockopt(SO_PEEK_OFF) syzbot reported a lockdep violation [1] involving af_unix support of SO_PEEK_OFF. Since SO_PEEK_OFF is inherently not thread safe (it uses a per-socket sk_peek_off field), there is really no point to enforce a pointless thread safety in the kernel. After this patch : – setsockopt(SO_PEEK_OFF) no longer acquires the socket lock. – skb_consume_udp() no longer has to acquire the socket lock. – af_unix no longer needs a special version of sk_set_peek_off(), because it does not lock u->iolock anymore. As a followup, we could replace prot->set_peek_off to be a boolean and avoid an indirect call, since we always use sk_set_peek_off(). [1] WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted syz-executor.2/30025 is trying to acquire lock: ffff8880765e7d80 (&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 but task is already holding lock: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_UNIX){+.+.}-{0:0}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_nested+0x48/0x100 net/core/sock.c:3524 lock_sock include/net/sock.h:1691 [inline] __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415 sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046 ____sys_recvmsg+0x3c0/0x470 net/socket.c:2801 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 -> #0 (&u->iolock){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789 sk_setsockopt+0x207e/0x3360 do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307 __sys_setsockopt+0x1ad/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 —- —- lock(sk_lock-AF_UNIX); lock(&u->iolock); lock(sk_lock-AF_UNIX); lock(&u->iolock); *** DEADLOCK *** 1 lock held by syz-executor.2/30025: #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline] #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193 stack backtrace: CPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Hardware name: Google Google C —truncated— 2024-04-03 not yet calculated CVE-2024-26732
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it’s not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let’s limit the max length of memcpy(). Note that commit b5f0de6df6dc (“net: dev: Convert sa_data to flexible array in struct sockaddr”) just silenced syzkaller. [0]: memcpy: detected field-spanning write (size 16) of single field “r->arp_ha.sa_data” at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> 2024-04-03 not yet calculated CVE-2024-26733
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: devlink: fix possible use-after-free and memory leaks in devlink_init() The pernet operations structure for the subsystem must be registered before registering the generic netlink family. Make an unregister in case of unsuccessful registration. 2024-04-03 not yet calculated CVE-2024-26734
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: ipv6: sr: fix possible use-after-free and null-ptr-deref The pernet operations structure for the subsystem must be registered before registering the generic netlink family. 2024-04-03 not yet calculated CVE-2024-26735
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: afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it’s 20 + NUL, so increase it to 24 and use snprintf()] 2024-04-03 not yet calculated CVE-2024-26736
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: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the “struct bpf_hrtimer”. Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period. 2024-04-03 not yet calculated CVE-2024-26737
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/iommu: DLPAR add doesn’t completely initialize pci_controller When a PCI device is dynamically added, the kernel oopses with a NULL pointer dereference: BUG: Kernel NULL pointer dereference on read at 0x00000030 Faulting instruction address: 0xc0000000006bbe5c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24002220 XER: 20040006 CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0 … NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Call Trace: iommu_init_device+0x26c/0x318 (unreliable) iommu_device_link+0x5c/0x118 iommu_init_device+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+0x44/0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_scan_pci_dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+0xb8/0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec Commit a940904443e4 (“powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains”) broke DLPAR add of PCI devices. The above added iommu_device structure to pci_controller. During system boot, PCI devices are discovered and this newly added iommu_device structure is initialized by a call to iommu_device_register(). During DLPAR add of a PCI device, a new pci_controller structure is allocated but there are no calls made to iommu_device_register() interface. Fix is to register the iommu device during DLPAR add as well. 2024-04-03 not yet calculated CVE-2024-26738
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: act_mirred: don’t override retval if we already lost the skb If we’re redirecting the skb, and haven’t called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it. 2024-04-03 not yet calculated CVE-2024-26739
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: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 (“act_mirred: use the backlog for nested calls to mirred ingress”) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. 2024-04-03 not yet calculated CVE-2024-26740
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: dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished(). syzkaller reported a warning [0] in inet_csk_destroy_sock() with no repro. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); However, the syzkaller’s log hinted that connect() failed just before the warning due to FAULT_INJECTION. [1] When connect() is called for an unbound socket, we search for an available ephemeral port. If a bhash bucket exists for the port, we call __inet_check_established() or __inet6_check_established() to check if the bucket is reusable. If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num. Later, we look up the corresponding bhash2 bucket and try to allocate it if it does not exist. Although it rarely occurs in real use, if the allocation fails, we must revert the changes by check_established(). Otherwise, an unconnected socket could illegally occupy an ehash entry. Note that we do not put tw back into ehash because sk might have already responded to a packet for tw and it would be better to free tw earlier under such memory presure. [0]: WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Modules linked in: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7f03e53852bb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170 </TASK> [1]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3748) kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867) inet_bind2_bucket_create —truncated— 2024-04-03 not yet calculated CVE-2024-26741
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: scsi: smartpqi: Fix disable_managed_interrupts Correct blk-mq registration issue with module parameter disable_managed_interrupts enabled. When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to register with blk-mq using blk_mq_map_queues(). The driver is currently calling blk_mq_pci_map_queues() which results in a stack trace and possibly undefined behavior. Stack Trace: [ 7.860089] scsi host2: smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.351193] process_one_work+0x1a7/0x360 [ 8.364462] ? create_worker+0x1a0/0x1a0 [ 8.379252] worker_thread+0x1ce/0x390 [ 8.392623] ? create_worker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? set_kthread_struct+0x50/0x50 [ 8.431532] ret_from_fork+0x1f/0x40 [ 8.444137] —[ end trace 1bf0173d39354506 ]— 2024-04-03 not yet calculated CVE-2024-26742
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: RDMA/qedr: Fix qedr_create_user_qp error flow Avoid the following warning by making sure to free the allocated resources in case that qedr_init_user_queue() fail. ———–[ cut here ]———– WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __warn+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x87c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 ? common_interrupt+0x43/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> –[ end trace 888a9b92e04c5c97 ]– 2024-04-03 not yet calculated CVE-2024-26743
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: RDMA/srpt: Support specifying the srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 2024-04-03 not yet calculated CVE-2024-26744
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/iommu: IOMMU table is not initialized for kdump over SR-IOV When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception: Kernel attempted to read user page (0) – exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 … NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0 At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window “ibm,dma-window” is removed from the FDT and DDW added, for the device. Now, kexec hands over control to the kdump kernel. When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no “ibm,dma-window”. The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables. iommu_table_setparms_lpar() only considers “ibm,dma-window” property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc(). The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember: 1. For the dedicated adapter, kdump kernel would encounter both default and DDW in FDT. In this case, DDW property is used to initialize the IOMMU table. 2. A DDW could be direct or dynamic mapped. kdump kernel would initialize IOMMU table and mark the existing DDW as “dynamic”. This works fine since, at the time of table initialization, iommu_table_clear() makes some space in the DDW, for some predefined number of TCEs which are needed for kdump to succeed. 2024-04-04 not yet calculated CVE-2024-26745
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: dmaengine: idxd: Ensure safe user copy of completion record If CONFIG_HARDENED_USERCOPY is enabled, copying completion record from event log cache to user triggers a kernel bug. [ 1987.159822] usercopy: Kernel memory exposure attempt detected from SLUB object ‘dsa0’ (offset 74, size 31)! [ 1987.170845] ————[ cut here ]———— [ 1987.176086] kernel BUG at mm/usercopy.c:102! [ 1987.180946] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 1987.186866] CPU: 17 PID: 528 Comm: kworker/17:1 Not tainted 6.8.0-rc2+ #5 [ 1987.194537] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 [ 1987.206405] Workqueue: wq0.0 idxd_evl_fault_work [idxd] [ 1987.212338] RIP: 0010:usercopy_abort+0x72/0x90 [ 1987.217381] Code: 58 65 9c 50 48 c7 c2 17 85 61 9c 57 48 c7 c7 98 fd 6b 9c 48 0f 44 d6 48 c7 c6 b3 08 62 9c 4c 89 d1 49 0f 44 f3 e8 1e 2e d5 ff <0f> 0b 49 c7 c1 9e 42 61 9c 4c 89 cf 4d 89 c8 eb a9 66 66 2e 0f 1f [ 1987.238505] RSP: 0018:ff62f5cf20607d60 EFLAGS: 00010246 [ 1987.244423] RAX: 000000000000005f RBX: 000000000000001f RCX: 0000000000000000 [ 1987.252480] RDX: 0000000000000000 RSI: ffffffff9c61429e RDI: 00000000ffffffff [ 1987.260538] RBP: ff62f5cf20607d78 R08: ff2a6a89ef3fffe8 R09: 00000000fffeffff [ 1987.268595] R10: ff2a6a89eed00000 R11: 0000000000000003 R12: ff2a66934849c89a [ 1987.276652] R13: 0000000000000001 R14: ff2a66934849c8b9 R15: ff2a66934849c899 [ 1987.284710] FS: 0000000000000000(0000) GS:ff2a66b22fe40000(0000) knlGS:0000000000000000 [ 1987.293850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1987.300355] CR2: 00007fe291a37000 CR3: 000000010fbd4005 CR4: 0000000000f71ef0 [ 1987.308413] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1987.316470] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1987.324527] PKRU: 55555554 [ 1987.327622] Call Trace: [ 1987.330424] <TASK> [ 1987.332826] ? show_regs+0x6e/0x80 [ 1987.336703] ? die+0x3c/0xa0 [ 1987.339988] ? do_trap+0xd4/0xf0 [ 1987.343662] ? do_error_trap+0x75/0xa0 [ 1987.347922] ? usercopy_abort+0x72/0x90 [ 1987.352277] ? exc_invalid_op+0x57/0x80 [ 1987.356634] ? usercopy_abort+0x72/0x90 [ 1987.360988] ? asm_exc_invalid_op+0x1f/0x30 [ 1987.365734] ? usercopy_abort+0x72/0x90 [ 1987.370088] __check_heap_object+0xb7/0xd0 [ 1987.374739] __check_object_size+0x175/0x2d0 [ 1987.379588] idxd_copy_cr+0xa9/0x130 [idxd] [ 1987.384341] idxd_evl_fault_work+0x127/0x390 [idxd] [ 1987.389878] process_one_work+0x13e/0x300 [ 1987.394435] ? __pfx_worker_thread+0x10/0x10 [ 1987.399284] worker_thread+0x2f7/0x420 [ 1987.403544] ? _raw_spin_unlock_irqrestore+0x2b/0x50 [ 1987.409171] ? __pfx_worker_thread+0x10/0x10 [ 1987.414019] kthread+0x107/0x140 [ 1987.417693] ? __pfx_kthread+0x10/0x10 [ 1987.421954] ret_from_fork+0x3d/0x60 [ 1987.426019] ? __pfx_kthread+0x10/0x10 [ 1987.430281] ret_from_fork_asm+0x1b/0x30 [ 1987.434744] </TASK> The issue arises because event log cache is created using kmem_cache_create() which is not suitable for user copy. Fix the issue by creating event log cache with kmem_cache_create_usercopy(), ensuring safe user copy. 2024-04-04 not yet calculated CVE-2024-26746
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: roles: fix NULL pointer issue when put module’s reference In current design, usb role class driver will get usb_role_switch parent’s module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module’s reference. This will save the module pointer in structure of usb_role_switch. Then, we don’t need to find module by iterating long relations. 2024-04-03 not yet calculated CVE-2024-26747
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: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request); Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn’t call usb_gadget_giveback_request() because it is allocated in this driver. 2024-04-03 not yet calculated CVE-2024-26748
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: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() … cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); … ‘priv_req’ actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem. 2024-04-03 not yet calculated CVE-2024-26749
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: af_unix: Drop oob_skb ref before purging queue in GC. syzbot reported another task hung in __unix_gc(). [0] The current while loop assumes that all of the left candidates have oob_skb and calling kfree_skb(oob_skb) releases the remaining candidates. However, I missed a case that oob_skb has self-referencing fd and another fd and the latter sk is placed before the former in the candidate list. Then, the while loop never proceeds, resulting the task hung. __unix_gc() has the same loop just before purging the collected skb, so we can call kfree_skb(oob_skb) there and let __skb_queue_purge() release all inflight sockets. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 2784 Comm: kworker/u4:8 Not tainted 6.8.0-rc4-syzkaller-01028-g71b605d32017 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: events_unbound __unix_gc RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200 Code: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0d 90 52 70 7e 65 8b 15 91 52 70 RSP: 0018:ffffc9000a17fa78 EFLAGS: 00000287 RAX: ffffffff8a0a6108 RBX: ffff88802b6c2640 RCX: ffff88802c0b3b80 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffc9000a17fbf0 R08: ffffffff89383f1d R09: 1ffff1100ee5ff84 R10: dffffc0000000000 R11: ffffed100ee5ff85 R12: 1ffff110056d84ee R13: ffffc9000a17fae0 R14: 0000000000000000 R15: ffffffff8f47b840 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffef5687ff8 CR3: 0000000029b34000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> __unix_gc+0xe69/0xf40 net/unix/garbage.c:343 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706 worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787 kthread+0x2ef/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> 2024-04-04 not yet calculated CVE-2024-26750
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: ARM: ep93xx: Add terminator to gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. 2024-04-03 not yet calculated CVE-2024-26751
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: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; …due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent. 2024-04-03 not yet calculated CVE-2024-26752
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: virtio/akcipher – Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o 2024-04-03 not yet calculated CVE-2024-26753
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: gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family. Syzkaller hit ‘general protection fault in gtp_genl_dump_pdp’ bug: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0 2024-04-03 not yet calculated CVE-2024-26754
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: md: Don’t suspend the array for interrupted reshape md_start_sync() will suspend the array if there are spares that can be added or removed from conf, however, if reshape is still in progress, this won’t happen at all or data will be corrupted(remove_and_add_spares won’t be called from md_choose_sync_action for reshape), hence there is no need to suspend the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupted; 2) set one of the disk WantReplacement, and add a new disk to the array, however, recovery won’t start until the reshape is finished; 3) then issue an IO across reshpae position, this IO will wait for reshape to make progress; 4) continue to reshape, then md_start_sync() found there is a spare disk that can be added to conf, mddev_suspend() is called; Step 4 and step 3 is waiting for each other, deadlock triggered. Noted this problem is found by code review, and it’s not reporduced yet. Fix this porblem by don’t suspend the array for interrupted reshape, this is safe because conf won’t be changed until reshape is done. 2024-04-03 not yet calculated CVE-2024-26755
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: md: Don’t register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case ‘MD_RECOVERY_RUNNING’ is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because ‘MD_RECOVERY_RUNNING’ can’t be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread. 2024-04-03 not yet calculated CVE-2024-26756
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: md: Don’t ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won’t register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 (“md: fix stopping sync thread”), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(…, !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can’t unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can’t be cleared, hence step 4 hang; The root cause is that dm-raid manipulate ‘mddev->ro’ by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of ‘mddev->ro’ in dm-raid, hence let’s fix the problem the easy way for now to prevent dm-raid regression. 2024-04-03 not yet calculated CVE-2024-26757
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: md: Don’t ignore suspended array in md_check_recovery() mddev_suspend() never stop sync_thread, hence it doesn’t make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can’t be unregistered. After commit f52f5c71f3d4 (“md: fix stopping sync thread”), following hang can be triggered by test shell/integrity-caching.sh: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(…, !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) daemon thread can’t unregister sync thread: md_check_recovery if (mddev->suspended) return; -> return directly md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING can’t be cleared, hence step 2 hang; This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend. 2024-04-03 not yet calculated CVE-2024-26758
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix race when skipping swapcache When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads swapin the same entry at the same time, they get different pages (A, B). Before one thread (T0) finishes the swapin and installs page (A) to the PTE, another thread (T1) could finish swapin of page (B), swap_free the entry, then swap out the possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, causing ABA problem. Thread (T0) will install a stalled page (A) into the PTE and cause data corruption. One possible callstack is like this: CPU0 CPU1 —- —- do_swap_page() do_swap_page() with same entry <direct swapin path> <direct swapin path> <alloc page A> <alloc page B> swap_read_folio() <- read to page A swap_read_folio() <- read to page B <slow on later locks or interrupt> <finished swapin first> … set_pte_at() swap_free() <- entry is free <write to page B, now page A stalled> <swap out page B to same swap entry> pte_same() <- Check pass, PTE seems unchanged, but page A is stalled! swap_free() <- page B content lost! set_pte_at() <- staled page A installed! And besides, for ZRAM, swap_free() allows the swap device to discard the entry content, so even if page (B) is not modified, if swap_read_folio() on CPU0 happens later than swap_free() on CPU1, it may also cause data loss. To fix this, reuse swapcache_prepare which will pin the swap entry using the cache flag, and allow only one thread to swap it in, also prevent any parallel code from putting the entry in the cache. Release the pin after PT unlocked. Racers just loop and wait since it’s a rare and very short event. A schedule_timeout_uninterruptible(1) call is added to avoid repeated page faults wasting too much CPU, causing livelock or adding too much noise to perf statistics. A similar livelock issue was described in commit 029c4628b2eb (“mm: swap: get rid of livelock in swapin readahead”) Reproducer: This race issue can be triggered easily using a well constructed reproducer and patched brd (with a delay in read path) [1]: With latest 6.8 mainline, race caused data loss can be observed easily: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Polulating 32MB of memory region… Keep swapping out… Starting round 0… Spawning 65536 workers… 32746 workers spawned, wait for done… Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss! Round 0 Failed, 15 data loss! This reproducer spawns multiple threads sharing the same memory region using a small swap device. Every two threads updates mapped pages one by one in opposite direction trying to create a race, with one dedicated thread keep swapping out the data out using madvise. The reproducer created a reproduce rate of about once every 5 minutes, so the race should be totally possible in production. After this patch, I ran the reproducer for over a few hundred rounds and no data loss observed. Performance overhead is minimal, microbenchmark swapin 10G from 32G zram: Before: 10934698 us After: 11157121 us Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag) [kasong@tencent.com: v4] Link: https://lkml.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com 2024-04-03 not yet calculated CVE-2024-26759
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: scsi: target: pscsi: Fix bio_put() for error case As of commit 066ff571011d (“block: turn bio_kmalloc into a simple kmalloc wrapper”), a bio allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in bio_free(). 2024-04-03 not yet calculated CVE-2024-26760
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: cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window The Linux CXL subsystem is built on the assumption that HPA == SPA. That is, the host physical address (HPA) the HDM decoder registers are programmed with are system physical addresses (SPA). During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1, 8.1.3.8) are checked if the memory is enabled and the CXL range is in a HPA window that is described in a CFMWS structure of the CXL host bridge (cxl-3.1, 9.18.1.3). Now, if the HPA is not an SPA, the CXL range does not match a CFMWS window and the CXL memory range will be disabled then. The HDM decoder stops working which causes system memory being disabled and further a system hang during HDM decoder initialization, typically when a CXL enabled kernel boots. Prevent a system hang and do not disable the HDM decoder if the decoder’s CXL range is not found in a CFMWS window. Note the change only fixes a hardware hang, but does not implement HPA/SPA translation. Support for this can be added in a follow on patch series. 2024-04-03 not yet calculated CVE-2024-26761
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: cxl/pci: Skip to handle RAS errors if CXL.mem device is detached The PCI AER model is an awkward fit for CXL error handling. While the expectation is that a PCI device can escalate to link reset to recover from an AER event, the same reset on CXL amounts to a surprise memory hotplug of massive amounts of memory. At present, the CXL error handler attempts some optimistic error handling to unbind the device from the cxl_mem driver after reaping some RAS register values. This results in a “hopeful” attempt to unplug the memory, but there is no guarantee that will succeed. A subsequent AER notification after the memdev unbind event can no longer assume the registers are mapped. Check for memdev bind before reaping status register values to avoid crashes of the form: BUG: unable to handle page fault for address: ffa00000195e9100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) – not-present page […] RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core] […] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? kernelmode_fixup_or_oops+0x84/0x110 ? exc_page_fault+0x113/0x170 ? asm_exc_page_fault+0x26/0x30 ? __pfx_dpc_reset_link+0x10/0x10 ? __cxl_handle_ras+0x30/0x110 [cxl_core] ? find_cxl_port+0x59/0x80 [cxl_core] cxl_handle_rp_ras+0xbc/0xd0 [cxl_core] cxl_error_detected+0x6c/0xf0 [cxl_core] report_error_detected+0xc7/0x1c0 pci_walk_bus+0x73/0x90 pcie_do_recovery+0x23f/0x330 Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might need to be replaced with a new PCI_ERS_RESULT_PANIC. 2024-04-03 not yet calculated CVE-2024-26762
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don’t modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/ 2024-04-03 not yet calculated CVE-2024-26763
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/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio. 2024-04-03 not yet calculated CVE-2024-26764
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: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 … Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58 2024-04-03 not yet calculated CVE-2024-26765
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: IB/hfi1: Fix sdma.h tx->num_descs off-by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] — [ 1080.974535] Call Trace: [ 1080.976990] <TASK> [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 — [ 1081.148347] __sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>, packet_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the descriptor array. With this patch the crashes are no longer reproducible and the machine is stable. 2024-04-03 not yet calculated CVE-2024-26766
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: fixed integer types and null check locations [why]: issues fixed: – comparison with wider integer type in loop condition which can cause infinite loops – pointer dereference before null check 2024-04-03 not yet calculated CVE-2024-26767
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: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With default config, the value of NR_CPUS is 64. When HW platform has more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC is the maximum cpu number in MADT table (max physical number) which can exceed the supported maximum cpu number (NR_CPUS, max logical number), but kernel should not crash. Kernel should boot cpus with NR_CPUS, let the remainder cpus stay in BIOS. The potential crash reason is that the array acpi_core_pic[NR_CPUS] can be overflowed when parsing MADT table, and it is obvious that CORE_PIC should be corresponding to physical core rather than logical core, so it is better to define the array as acpi_core_pic[MAX_CORE_PIC]. With the patch, system can boot up 64 vcpus with qemu parameter -smp 128, otherwise system will crash with the following message. [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192 [ 0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60 [ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8 [ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005 [ 0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001 [ 0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063 [ 0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98 [ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90 [ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330 [ 0.000000] ra: 90000000037a46ec platform_init+0x214/0x250 [ 0.000000] ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94 [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 0.000000] BADV: 0000420000004259 [ 0.000000] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec [ 0.000000] 000000000a7fd000 0000000008290000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 00000000019d8000 000000000f556b60 [ 0.000000] 000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000 [ 0.000000] 9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c [ 0.000000] 000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08 [ 0.000000] 9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018 [ 0.000000] 000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000 [ 0.000000] 0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000 [ 0.000000] 000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000 [ 0.000000] … [ 0.000000] Call Trace: [ 0.000000] [<90000000037a5f0c>] efi_runtime_init+0x30/0x94 [ 0.000000] [<90000000037a46ec>] platform_init+0x214/0x250 [ 0.000000] [<90000000037a484c>] setup_arch+0x124/0x45c [ 0.000000] [<90000000037a0790>] start_kernel+0x90/0x670 [ 0.000000] [<900000000378b0d8>] kernel_entry+0xd8/0xdc 2024-04-03 not yet calculated CVE-2024-26768
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-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item. 2024-04-03 not yet calculated CVE-2024-26769
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: HID: nvidia-shield: Add missing null pointer checks to LED initialization devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. [jkosina@suse.com: tweak changelog a bit] 2024-04-03 not yet calculated CVE-2024-26770
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: dmaengine: ti: edma: Add some null pointer checks to the edma_probe devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. 2024-04-03 not yet calculated CVE-2024-26771
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: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group’s block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap. 2024-04-03 not yet calculated CVE-2024-26772
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: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn’t use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group 2024-04-03 not yet calculated CVE-2024-26773
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: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Determine if bb_fragments is 0 instead of determining bb_free to eliminate the risk of dividing by zero when the block bitmap is corrupted. 2024-04-03 not yet calculated CVE-2024-26774
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: aoe: avoid potential deadlock at set_capacity Move set_capacity() outside of the section procected by (&d->lock). To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 —- —- [1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); <Interrupt> [4] lock(&d->lock); *** DEADLOCK *** Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity(). [2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc() is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call. In this situation an attempt to acquire [4]lock(&d->lock) from aoecmd_cfg_rsp() will lead to deadlock. So the simplest solution is breaking lock dependency [2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity() outside. 2024-04-03 not yet calculated CVE-2024-26775
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: spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc 2024-04-03 not yet calculated CVE-2024-26776
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: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn’t check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. 2024-04-03 not yet calculated CVE-2024-26777
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: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn’t check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. 2024-04-03 not yet calculated CVE-2024-26778
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: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. 2024-04-03 not yet calculated CVE-2024-26779
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: af_unix: Fix task hung while purging oob_skb in GC. syzbot reported a task hung; at the same time, GC was looping infinitely in list_for_each_entry_safe() for OOB skb. [0] syzbot demonstrated that the list_for_each_entry_safe() was not actually safe in this case. A single skb could have references for multiple sockets. If we free such a skb in the list_for_each_entry_safe(), the current and next sockets could be unlinked in a single iteration. unix_notinflight() uses list_del_init() to unlink the socket, so the prefetched next socket forms a loop itself and list_for_each_entry_safe() never stops. Here, we must use while() and make sure we always fetch the first socket. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline] RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline] RIP: 0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207 Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74 RSP: 0018:ffffc900033efa58 EFLAGS: 00000283 RAX: ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189 RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70 RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c R10: ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800 R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> unix_gc+0x563/0x13b0 net/unix/garbage.c:319 unix_release_sock+0xa93/0xf80 net/unix/af_unix.c:683 unix_release+0x91/0xf0 net/unix/af_unix.c:1064 __sock_release+0xb0/0x270 net/socket.c:659 sock_close+0x1c/0x30 net/socket.c:1421 __fput+0x270/0xb80 fs/file_table.c:376 task_work_run+0x14f/0x250 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xa8a/0x2ad0 kernel/exit.c:871 do_group_exit+0xd4/0x2a0 kernel/exit.c:1020 __do_sys_exit_group kernel/exit.c:1031 [inline] __se_sys_exit_group kernel/exit.c:1029 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f9d6cbdac09 Code: Unable to access opcode bytes at 0x7f9d6cbdabdf. RSP: 002b:00007fff5952feb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9d6cbdac09 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007f9d6cc552b0 R08: ffffffffffffffb8 R09: 0000000000000006 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f9d6cc552b0 R13: 0000000000000000 R14: 00007f9d6cc55d00 R15: 00007f9d6cbabe70 </TASK> 2024-04-04 not yet calculated CVE-2024-26780
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: mptcp: fix possible deadlock in subflow diag Syzbot and Eric reported a lockdep splat in the subflow diag: WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 -> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 As noted by Eric we can break the lock dependency chain avoid dumping —truncated— 2024-04-04 not yet calculated CVE-2024-26781
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: mptcp: fix double-free on socket dismantle when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to ‘inet_opt’ for the new socket has the same value as the original one: as a consequence, on program exit it’s possible to observe the following splat: BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0 CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0 __do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidle_enter+0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 secondary_startup_64_no_verify+0x184/0x18b </TASK> Allocated by task 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 __kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_netlbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 security_socket_post_create+0x63/0xb0 __sock_create+0x305/0x450 __sys_socket_create.part.23+0xbd/0x130 __sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 6858: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy_sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0 __netif_receive_skb_one_core+0x16e/0x1b0 process_backlog+0x1e3/0x650 __napi_poll+0xa6/0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4 The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0) The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888485950780: fa fb fb —truncated— 2024-04-04 not yet calculated CVE-2024-26782
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: mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn’t have its local memory so it has no managed zones, the following oops has been observed. It’s because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) – not-present page > PGD 0 P4D 0 > Oops: 0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS: 00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP: 002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> 2024-04-04 not yet calculated CVE-2024-26783
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: pmdomain: arm: Fix NULL dereference on scmi_perf_domain removal On unloading of the scmi_perf_domain module got the below splat, when in the DT provided to the system under test the ‘#power-domain-cells’ property was missing. Indeed, this particular setup causes the probe to bail out early without giving any error, which leads to the ->remove() callback gets to run too, but without all the expected initialized structures in place. Add a check and bail out early on remove too. Call trace: scmi_perf_domain_remove+0x28/0x70 [scmi_perf_domain] scmi_dev_remove+0x28/0x40 [scmi_core] device_remove+0x54/0x90 device_release_driver_internal+0x1dc/0x240 driver_detach+0x58/0xa8 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x70 scmi_driver_unregister+0x28/0x180 [scmi_core] scmi_perf_domain_driver_exit+0x18/0xb78 [scmi_perf_domain] __arm64_sys_delete_module+0x1a8/0x2c0 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0xb8 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x190/0x198 Code: a90153f3 f9403c14 f9414800 955f8a05 (b9400a80) —[ end trace 0000000000000000 ]— 2024-04-04 not yet calculated CVE-2024-26784
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix protection fault in iommufd_test_syz_conv_iova Syzkaller reported the following bug: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lock_acquire lock_acquire+0x1ce/0x4f0 down_read+0x93/0x4a0 iommufd_test_syz_conv_iova+0x56/0x1f0 iommufd_test_access_rw.isra.0+0x2ec/0x390 iommufd_test+0x1058/0x1e30 iommufd_fops_ioctl+0x381/0x510 vfs_ioctl __do_sys_ioctl __se_sys_ioctl __x64_sys_ioctl+0x170/0x1e0 do_syscall_x64 do_syscall_64+0x71/0x140 This is because the new iommufd_access_change_ioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context. Fix this by doing the same access->ioas sanity as iommufd_access_rw() and iommufd_access_pin_pages() functions do. 2024-04-04 not yet calculated CVE-2024-26785
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix iopt_access_list_id overwrite bug Syzkaller reported the following WARN_ON: WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/io_pagetable.c:1360 Call Trace: iommufd_access_change_ioas+0x2fe/0x4e0 iommufd_access_destroy_object+0x50/0xb0 iommufd_object_remove+0x2a3/0x490 iommufd_object_destroy_user iommufd_access_destroy+0x71/0xb0 iommufd_test_staccess_release+0x89/0xd0 __fput+0x272/0xb50 __fput_sync+0x4b/0x60 __do_sys_close __se_sys_close __x64_sys_close+0x8b/0x110 do_syscall_x64 The mismatch between the access pointer in the list and the passed-in pointer is resulting from an overwrite of access->iopt_access_list_id, in iopt_add_access(). Called from iommufd_access_change_ioas() when xa_alloc() succeeds but iopt_calculate_iova_alignment() fails. Add a new_id in iopt_add_access() and only update iopt_access_list_id when returning successfully. 2024-04-04 not yet calculated CVE-2024-26786
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: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren’t supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path. 2024-04-04 not yet calculated CVE-2024-26787
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: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don’t get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18 2024-04-04 not yet calculated CVE-2024-26788
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: arm64/neonbs – fix out-of-bounds access on short input The bit-sliced implementation of AES-CTR operates on blocks of 128 bytes, and will fall back to the plain NEON version for tail blocks or inputs that are shorter than 128 bytes to begin with. It will call straight into the plain NEON asm helper, which performs all memory accesses in granules of 16 bytes (the size of a NEON register). For this reason, the associated plain NEON glue code will copy inputs shorter than 16 bytes into a temporary buffer, given that this is a rare occurrence and it is not worth the effort to work around this in the asm code. The fallback from the bit-sliced NEON version fails to take this into account, potentially resulting in out-of-bounds accesses. So clone the same workaround, and use a temp buffer for short in/outputs. 2024-04-04 not yet calculated CVE-2024-26789
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: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ). Implement this workaround. 2024-04-04 not yet calculated CVE-2024-26790
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: dev-replace: properly validate device names There’s a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links). 2024-04-04 not yet calculated CVE-2024-26791
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 double free of anonymous device after snapshot creation failure When creating a snapshot we may do a double free of an anonymous device in case there’s an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem. The steps that lead to this: 1) At ioctl.c:create_snapshot() we allocate an anonymous device number and assign it to pending_snapshot->anon_dev; 2) Then we call btrfs_commit_transaction() and end up at transaction.c:create_pending_snapshot(); 3) There we call btrfs_get_new_fs_root() and pass it the anonymous device number stored in pending_snapshot->anon_dev; 4) btrfs_get_new_fs_root() frees that anonymous device number because btrfs_lookup_fs_root() returned a root – someone else did a lookup of the new root already, which could some task doing backref walking; 5) After that some error happens in the transaction commit path, and at ioctl.c:create_snapshot() we jump to the ‘fail’ label, and after that we free again the same anonymous device number, which in the meanwhile may have been reallocated somewhere else, because pending_snapshot->anon_dev still has the same value as in step 1. Recently syzbot ran into this and reported the following trace: ————[ cut here ]———— ida_free called for id=51 which is not allocated. WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Modules linked in: CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Code: 10 42 80 3c 28 (…) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Call Trace: <TASK> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Code: 28 00 00 00 (…) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 </TASK> Where we get an explicit message where we attempt to free an anonymous device number that is not currently allocated. It happens in a different code path from the example below, at btrfs_get_root_ref(), so this change may not fix the case triggered by sy —truncated— 2024-04-04 not yet calculated CVE-2024-26792
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: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit ‘general protection fault in gtp_genl_dump_pdp’ bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map —truncated— 2024-04-04 not yet calculated CVE-2024-26793
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 race between ordered extent completion and fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). However by not locking the target extent range for the whole duration of the fiemap call we can race with an ordered extent. This happens like this: 1) The fiemap task finishes processing a file extent item that covers the file range [512K, 1M[, and that file extent item is the last item in the leaf currently being processed; 2) And ordered extent for the file range [768K, 2M[, in COW mode, completes (btrfs_finish_one_ordered()) and the file extent item covering the range [512K, 1M[ is trimmed to cover the range [512K, 768K[ and then a new file extent item for the range [768K, 2M[ is inserted in the inode’s subvolume tree; 3) The fiemap task calls fiemap_next_leaf_item(), which then calls btrfs_next_leaf() to find the next leaf / item. This finds that the the next key following the one we previously processed (its type is BTRFS_EXTENT_DATA_KEY and its offset is 512K), is the key corresponding to the new file extent item inserted by the ordered extent, which has a type of BTRFS_EXTENT_DATA_KEY and an offset of 768K; 4) Later the fiemap code ends up at emit_fiemap_extent() and triggers the warning: if (cache->offset + cache->len > offset) { WARN_ON(1); return -EINVAL; } Since we get 1M > 768K, because the previously emitted entry for the old extent covering the file range [512K, 1M[ ends at an offset that is greater than the new extent’s start offset (768K). This makes fiemap fail with -EINVAL besides triggering the warning that produces a stack trace like the following: [1621.677651] ————[ cut here ]———— [1621.677656] WARNING: CPU: 1 PID: 204366 at fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs] [1621.677899] Modules linked in: btrfs blake2b_generic (…) [1621.677951] CPU: 1 PID: 204366 Comm: pool Not tainted 6.8.0-rc5-btrfs-next-151+ #1 [1621.677954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678033] Code: 2b 4c 89 63 (…) [1621.678035] RSP: 0018:ffffab16089ffd20 EFLAGS: 00010206 [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000 [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI: ffffab16089ffe90 [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 0000000000000000 [1621.678041] R10: 0000000000000000 R11: 0000000000001000 R12: 0000000041d78000 [1621.678043] R13: 0000000000001000 R14: 0000000000000000 R15: ffff9434f0b17850 [1621.678044] FS: 00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) knlGS:0000000000000000 [1621.678046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1621.678048] CR2: 00007fa6b0801000 CR3: 000000012d404002 CR4: 0000000000370ef0 [1621.678053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1621.678055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1621.678056] Call Trace: [1621.678074] <TASK> [1621.678076] ? __warn+0x80/0x130 [1621.678082] ? emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678159] ? report_bug+0x1f4/0x200 [1621.678164] ? handle_bug+0x42/0x70 [1621.678167] ? exc_invalid_op+0x14/0x70 [1621.678170] ? asm_exc_invalid_op+0x16/0x20 [1621.678178] ? emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678253] extent_fiemap+0x766 —truncated— 2024-04-04 not yet calculated CVE-2024-26794
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: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex’s comments 2024-04-04 not yet calculated CVE-2024-26795
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: drivers: perf: ctr_get_width function for legacy is not defined With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n linux kernel crashes when you try perf record: $ perf record ls [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 46.750199] Oops [#1] [ 46.750342] Modules linked in: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Hardware name: riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e [ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0 [ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000 [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004 [ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2 [ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000 [ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078 [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001 [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30 [ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec. [ 46.754939] —[ end trace 0000000000000000 ]— [ 46.755131] note: perf-exec[107] exited with irqs disabled [ 46.755546] note: perf-exec[107] exited with preempt_count 4 This happens because in the legacy case the ctr_get_width function was not defined, but it is used in arch_perf_update_userpage. Also remove extra check in riscv_pmu_ctr_get_width_mask 2024-04-04 not yet calculated CVE-2024-26796
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: Prevent potential buffer overflow in map_hw_resources Adds a check in the map_hw_resources function to prevent a potential buffer overflow. The function was accessing arrays using an index that could potentially be greater than the size of the arrays, leading to a buffer overflow. Adds a check to ensure that the index is within the bounds of the arrays. If the index is out of bounds, an error message is printed and break it will continue execution with just ignoring extra data early to prevent the buffer overflow. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow ‘dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id’ 6 <= 7 drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 map_hw_resources() error: buffer overflow ‘dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id’ 6 <= 7 2024-04-04 not yet calculated CVE-2024-26797
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the “system”/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by Syzkaller to crash the system on the next invocation of font_get(). It’s rather hard to hit the allocation failure in vc_resize() on the first font_set(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) – not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] … So restore the font data in any case, not only for user fonts. Note the later ‘if’ is now protected by ‘old_userfont’ and not ‘old_data’ as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.) 2024-04-04 not yet calculated CVE-2024-26798
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: qcom: Fix uninitialized pointer dmactl In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params. Cleans up clang scan build warning: sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch] 2024-04-04 not yet calculated CVE-2024-26799
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: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released. 2024-04-04 not yet calculated CVE-2024-26800
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: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here’s the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash. 2024-04-04 not yet calculated CVE-2024-26801
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: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won’t work and TX queue will eventually timeout, causing ‘Reset adapter’ error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying workqueue. Log/backtrace from crash goes as follows: [88.031977]————[ cut here ]———— [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 <Skipping backtrace for watchdog timeout> [88.032251]—[ end trace e70de432e4d5c2c0 ]— [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]————[ cut here ]———— [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]—[ end trace e70de432e4d5c2c1 ]— [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 2024-04-04 not yet calculated CVE-2024-26802
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: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there’s nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we’ll end up with a stray GRO flag set but no NAPI instances. We don’t depend on the GRO flag on the datapath, so the datapath won’t crash. We will crash (or hang), however, next time features are sync’ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we’ll hang in napi_disable(). If it never was we’ll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths. 2024-04-04 not yet calculated CVE-2024-26803
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: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 … ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 … The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); … but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets “adjusted” by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets’ ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely. 2024-04-04 not yet calculated CVE-2024-26804
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: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages —truncated— 2024-04-04 not yet calculated CVE-2024-26805
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: spi: cadence-qspi: remove system-wide suspend helper calls from runtime PM hooks The ->runtime_suspend() and ->runtime_resume() callbacks are not expected to call spi_controller_suspend() and spi_controller_resume(). Remove calls to those in the cadence-qspi driver. Those helpers have two roles currently: – They stop/start the queue, including dealing with the kworker. – They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It requires acquiring ctlr->bus_lock_mutex. Step one is irrelevant because cadence-qspi is not queued. Step two however has two implications: – A deadlock occurs, because ->runtime_resume() is called in a context where the lock is already taken (in the ->exec_op() callback, where the usage count is incremented). – It would disallow all operations once the device is auto-suspended. Here is a brief call tree highlighting the mutex deadlock: spi_mem_exec_op() … spi_mem_access_start() mutex_lock(&ctlr->bus_lock_mutex) cqspi_exec_mem_op() pm_runtime_resume_and_get() cqspi_resume() spi_controller_resume() mutex_lock(&ctlr->bus_lock_mutex) … spi_mem_access_end() mutex_unlock(&ctlr->bus_lock_mutex) … 2024-04-04 not yet calculated CVE-2024-26806
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: spi: cadence-qspi: fix pointer reference in runtime PM hooks dev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI controller. Neither embed the other; this lead to memory corruption. On a given platform (Mobileye EyeQ5) the memory corruption is hidden inside cqspi->f_pdata. Also, this uninitialised memory is used as a mutex (ctlr->bus_lock_mutex) by spi_controller_suspend(). 2024-04-04 not yet calculated CVE-2024-26807
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: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list. 2024-04-04 not yet calculated CVE-2024-26808
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: nft_set_pipapo: release elements in clone only from destroy path Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice. This fix requires: 212ed75dc5fb (“netfilter: nf_tables: integrate pipapo into commit protocol”) which came after: 9827a0e6e23b (“netfilter: nft_set_pipapo: release elements in clone from abort path”). 2024-04-04 not yet calculated CVE-2024-26809
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: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows. 2024-04-05 not yet calculated CVE-2024-26810
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: vfio/pci: Create persistent INTx handler A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending. Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace. As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks. 2024-04-05 not yet calculated CVE-2024-26812
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: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it’s guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index. 2024-04-05 not yet calculated CVE-2024-26813
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: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged. 2024-04-05 not yet calculated CVE-2024-26814
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: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required. 2024-04-05 not yet calculated CVE-2024-27437
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 ly_corporation — ‘yahoo!_japan’_app_for_android
  ‘Yahoo! JAPAN’ App for Android v2.3.1 to v3.161.1 and ‘Yahoo! JAPAN’ App for iOS v3.2.2 to v4.109.0 contain a cross-site scripting vulnerability. If this vulnerability is exploited, an arbitrary script may be executed on the WebView of ‘Yahoo! JAPAN’ App via other app installed on the user’s device. 2024-04-01 not yet calculated CVE-2024-28895
vultures@jpcert.or.jp mediatek,_inc. — mt2713,_mt2737,_mt6781,_mt6789,_mt6835,_mt6855,_mt6879,_mt6880,_mt6886,_mt6890,_mt6895,_mt6980,_mt6983,_mt6985,_mt6989,_mt6990,_mt8167,_mt8168,_mt8173,_mt8175,_mt8188,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8390,_mt8395,_mt8666,_mt8667,_mt8673,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In flashc, there is a possible information disclosure due to an uncaught exception. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541765; Issue ID: ALPS08541765. 2024-04-01 not yet calculated CVE-2024-20049
security@mediatek.com mediatek,_inc. — mt2713,_mt2737,_mt6781,_mt6789,_mt6835,_mt6855,_mt6879,_mt6880,_mt6886,_mt6890,_mt6895,_mt6980,_mt6983,_mt6985,_mt6989,_mt6990,_mt8167,_mt8168,_mt8173,_mt8175,_mt8188,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8390,_mt8395,_mt8666,_mt8667,_mt8673,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In flashc, there is a possible information disclosure due to an uncaught exception. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541757; Issue ID: ALPS08541757. 2024-04-01 not yet calculated CVE-2024-20050
security@mediatek.com mediatek,_inc. — mt2713,_mt2737,_mt6781,_mt6789,_mt6835,_mt6855,_mt6879,_mt6880,_mt6886,_mt6890,_mt6895,_mt6980,_mt6983,_mt6985,_mt6989,_mt6990,_mt8167,_mt8168,_mt8173,_mt8175,_mt8188,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8390,_mt8395,_mt8666,_mt8667,_mt8673,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In flashc, there is a possible system crash due to an uncaught exception. This could lead to local denial of service with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541757; Issue ID: ALPS08541758. 2024-04-01 not yet calculated CVE-2024-20051
security@mediatek.com mediatek,_inc. — mt2713,_mt2737,_mt6781,_mt6789,_mt6835,_mt6855,_mt6879,_mt6880,_mt6886,_mt6890,_mt6895,_mt6980,_mt6983,_mt6985,_mt6989,_mt6990,_mt8167,_mt8168,_mt8173,_mt8175,_mt8188,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8390,_mt8395,_mt8666,_mt8667,_mt8673,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In flashc, there is a possible information disclosure due to an uncaught exception. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541757; Issue ID: ALPS08541761. 2024-04-01 not yet calculated CVE-2024-20052
security@mediatek.com mediatek,_inc. — mt2713,_mt2737,_mt6781,_mt6789,_mt6835,_mt6855,_mt6879,_mt6880,_mt6886,_mt6890,_mt6895,_mt6980,_mt6983,_mt6985,_mt6989,_mt6990,_mt8167,_mt8168,_mt8173,_mt8175,_mt8188,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8390,_mt8395,_mt8666,_mt8667,_mt8673,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In flashc, there is a possible out of bounds write due to an uncaught exception. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541757; Issue ID: ALPS08541764. 2024-04-01 not yet calculated CVE-2024-20053
security@mediatek.com mediatek,_inc. — mt2713,_mt6580,_mt6761,_mt6762,_mt6768,_mt6781,_mt6789,_mt6833,_mt6853,_mt6853t,_mt6855,_mt6873,_mt6875,_mt6877,_mt6879,_mt6883,_mt6885,_mt6886,_mt6889,_mt6890,_mt6891,_mt6893,_mt6895,_mt6983,_mt6985,_mt6989,_mt6990,_mt7902,_mt7915,_mt7916,_mt7920,_mt7921,_mt7922,_mt7925,_mt7927,_mt7981,_mt7986,_mt8188,_mt8195,_mt8370,_mt8390,_mt8395,_mt8518s,_mt8532,_mt8673,_mt8678,_mt8781,_mt8791t,_mt8792,_mt8796,_mt8797,_mt8798
  In wlan firmware, there is a possible out of bounds write due to improper input validation. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08360153 (for MT6XXX chipsets) / WCNCR00363530 (for MT79XX chipsets); Issue ID: MSV-979. 2024-04-01 not yet calculated CVE-2024-20040
security@mediatek.com mediatek,_inc. — mt2713,_mt6781,_mt6789,_mt6835,_mt6855,_mt6879,_mt6886,_mt6895,_mt6983,_mt6985,_mt6989,_mt8167,_mt8168,_mt8173,_mt8175,_mt8188,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8390,_mt8395,_mt8666,_mt8667,_mt8673,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In flashc, there is a possible information disclosure due to an uncaught exception. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541769; Issue ID: ALPS08541769. 2024-04-01 not yet calculated CVE-2024-20048
security@mediatek.com mediatek,_inc. — mt2713,_mt6781,_mt6789,_mt6835,_mt6855,_mt6879,_mt6886,_mt6895,_mt6983,_mt6985,_mt6989,_mt8188,_mt8673,_mt8676,_mt8781
  In da, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541746; Issue ID: ALPS08541746. 2024-04-01 not yet calculated CVE-2024-20041
security@mediatek.com mediatek,_inc. — mt2713,_mt8168,_mt8173,_mt8175,_mt8188,_mt8195,_mt8365,_mt8370,_mt8390,_mt8395,_mt8673,_mt8696,_mt8781,_mt8795t,_mt8798,_mt8871
  In imgsys, there is a possible information disclosure due to a missing bounds check. This could lead to local information disclosure with System execution privileges needed. User interaction is needed for exploitation Patch ID: ALPS08518692; Issue ID: MSV-1012. 2024-04-01 not yet calculated CVE-2024-20055
security@mediatek.com mediatek,_inc. — mt2731,_mt2735,_mt2737,_mt3967,_mt6297,_mt6298,_mt6739,_mt6761,_mt6762,_mt6762d,_mt6762m,_mt6763,_mt6765,_mt6765t,_mt6767,_mt6768,_mt6769,_mt6769t,_mt6769z,_mt6771,_mt6779,_mt6781,_mt6783,_mt6785,_mt6785t,_mt6785u,_mt6789,_mt6813,_mt6815,_mt6833,_mt6835,_mt6853,_mt6855,_mt6873,_mt6875,_mt6875t,_mt6877,_mt6879,_mt6880,_mt6883,_mt6885,_mt6886,_mt6889,_mt6890,_mt6891,_mt6893,_mt6895,_mt6895t,_mt6896,_mt6897,_mt6980,_mt6980d,_mt6983,_mt6985,_mt6986,_mt6986d,_mt6989,_mt6990,_mt8666,_mt8667,_mt8673,_mt8675,_mt8676,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8791,_mt8791t,_mt8792,_mt8796,_mt8797,_mt8798
  In modem protocol, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01240012; Issue ID: MSV-1215. 2024-04-01 not yet calculated CVE-2024-20039
security@mediatek.com mediatek,_inc. — mt2735,_mt2737,_mt6762,_mt6765,_mt6769,_mt6833,_mt6835,_mt6853,_mt6855,_mt6873,_mt6875,_mt6877,_mt6879,_mt6883,_mt6885,_mt6889,_mt6890,_mt6891,_mt6893,_mt6895,_mt6983,_mt6985,_mt6989,_mt6990,_mt8168,_mt8173,_mt8195,_mt8321,_mt8385,_mt8390,_mt8666,_mt8667,_mt8673,_mt8676,_mt8678,_mt8755,_mt8765,_mt8766,_mt8768,_mt8775,_mt8781,_mt8786,_mt8788,_mt8791t,_mt8792,_mt8796,_mt8893
  In gnss, there is a possible escalation of privilege due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08580200; Issue ID: ALPS08580200. 2024-04-01 not yet calculated CVE-2024-20054
security@mediatek.com mediatek,_inc. — mt6739,_mt6757,_mt6761,_mt6763,_mt6765,_mt6768,_mt6771,_mt6779,_mt6781,_mt6785,_mt6833,_mt6853,_mt6873,_mt6877,_mt6885,_mt6893,_mt8167,_mt8168,_mt8173,_mt8175,_mt8183,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8395,_mt8666,_mt8673,_mt8678,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In da, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541780; Issue ID: ALPS08541780. 2024-04-01 not yet calculated CVE-2024-20042
security@mediatek.com mediatek,_inc. — mt6739,_mt6757,_mt6761,_mt6763,_mt6765,_mt6768,_mt6771,_mt6779,_mt6781,_mt6785,_mt6833,_mt6853,_mt6873,_mt6877,_mt6885,_mt6893,_mt8167,_mt8168,_mt8173,_mt8175,_mt8185,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8395,_mt8666,_mt8673,_mt8678,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In da, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541781; Issue ID: ALPS08541781. 2024-04-01 not yet calculated CVE-2024-20043
security@mediatek.com mediatek,_inc. — mt6739,_mt6757,_mt6761,_mt6763,_mt6765,_mt6768,_mt6771,_mt6779,_mt6781,_mt6785,_mt6833,_mt6853,_mt6873,_mt6877,_mt6885,_mt6893,_mt8167,_mt8168,_mt8173,_mt8175,_mt8185,_mt8195,_mt8321,_mt8362a,_mt8365,_mt8385,_mt8395,_mt8666,_mt8673,_mt8678,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8791t,_mt8796,_mt8797,_mt8798
  In da, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08541784; Issue ID: ALPS08541784. 2024-04-01 not yet calculated CVE-2024-20044
security@mediatek.com mediatek,_inc. — mt6739,_mt6768,_mt6781,_mt6833,_mt6853,_mt6877,_mt6883,_mt6885,_mt6893,_mt8183,_mt8188,_mt8765,_mt8766,_mt8768,_mt8786,_mt8788,_mt8791,_mt8797
  In battery, there is a possible out of bounds read due to an integer overflow. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08587865; Issue ID: ALPS08486807. 2024-04-01 not yet calculated CVE-2024-20047
security@mediatek.com mediatek,_inc. — mt6761,_mt6765,_mt6768,_mt6789,_mt6833,_mt6855,_mt6895,_mt8167,_mt8168,_mt8188,_mt8321,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791t,_mt8797,_mt8798
  In battery, there is a possible escalation of privilege due to an integer overflow. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08485622; Issue ID: ALPS08485622. 2024-04-01 not yet calculated CVE-2024-20046
security@mediatek.com mediatek,_inc. — mt6833,_mt6835,_mt6853,_mt6853t,_mt6855,_mt6873,_mt6875,_mt6877,_mt6879,_mt6883,_mt6885,_mt6886,_mt6889,_mt6983,_mt6985,_mt6989,_mt8167,_mt8167s,_mt8168,_mt8188,_mt8195,_mt8321,_mt8385,_mt8765,_mt8766,_mt8768,_mt8781,_mt8786,_mt8788,_mt8789,_mt8791,_mt8797,_mt8798
  In audio, there is a possible out of bounds read due to an incorrect calculation of buffer size. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08024748; Issue ID: ALPS08029526. 2024-04-01 not yet calculated CVE-2024-20045
security@mediatek.com mozilla — firefox_for_ios
  If an insecure element was added to a page after a delay, Firefox would not replace the secure icon with a mixed content security status This vulnerability affects Firefox for iOS < 124. 2024-04-03 not yet calculated CVE-2024-31392
security@mozilla.org
security@mozilla.org mozilla — firefox_for_ios
  Dragging Javascript URLs to the address bar could cause them to be loaded, bypassing restrictions and security protections This vulnerability affects Firefox for iOS < 124. 2024-04-03 not yet calculated CVE-2024-31393
security@mozilla.org
security@mozilla.org mudler — mudler/localai
  The web server lacked CSRF tokens allowing an attacker to host malicious JavaScript on a host that when visited by a LocalAI user, could allow the attacker to fill disk space to deny service or abuse credits. 2024-04-01 not yet calculated CVE-2024-3135
security@huntr.dev pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor Updater Improper Certificate Validation Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of PDF-XChange Editor. User interaction is not required to exploit this vulnerability. The specific flaw exists within the update functionality. The issue results from the lack of proper validation of the certificate presented by the server. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-22224. 2024-04-01 not yet calculated CVE-2024-27323
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor TIF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of TIF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22270. 2024-04-01 not yet calculated CVE-2024-27324
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor EMF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of EMF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22275. 2024-04-01 not yet calculated CVE-2024-27325
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor XPS File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of XPS files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22276. 2024-04-01 not yet calculated CVE-2024-27326
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor PDF File Parsing Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-22277. 2024-04-01 not yet calculated CVE-2024-27327
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor EMF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of EMF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22280. 2024-04-01 not yet calculated CVE-2024-27328
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor XPS File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of XPS files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22285. 2024-04-01 not yet calculated CVE-2024-27329
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor EMF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of EMF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22286. 2024-04-01 not yet calculated CVE-2024-27330
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor EMF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of EMF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22287. 2024-04-01 not yet calculated CVE-2024-27331
zdi-disclosures@trendmicro.com pdf-xchange — pdf-xchange_editor
  PDF-XChange Editor JPG File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of JPG files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-22288. 2024-04-01 not yet calculated CVE-2024-27332
zdi-disclosures@trendmicro.com rarlab — winrar
  RARLAB WinRAR Mark-Of-The-Web Bypass Vulnerability. This vulnerability allows remote attackers to bypass the Mark-Of-The-Web protection mechanism on affected installations of RARLAB WinRAR. User interaction is required to exploit this vulnerability in that the target must perform a specific action on a malicious page. The specific flaw exists within the archive extraction functionality. A crafted archive entry can cause the creation of an arbitrary file without the Mark-Of-The-Web. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current user. Was ZDI-CAN-23156. 2024-04-02 not yet calculated CVE-2024-30370
zdi-disclosures@trendmicro.com
zdi-disclosures@trendmicro.com sante — pacs_server
  Sante PACS Server Token Endpoint SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Sante PACS Server. Authentication is not required to exploit this vulnerability. The specific flaw exists within the processing of HTTP requests on port 3000. When parsing the token parameter, the process does not properly validate a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of NETWORK SERVICE. Was ZDI-CAN-21539. 2024-04-01 not yet calculated CVE-2024-1863
zdi-disclosures@trendmicro.com seenergy_corp. — svr-116
  SVR-116 firmware version 1.6.0.30028871 allows a remote authenticated attacker with an administrative privilege to execute arbitrary OS commands by sending a specially crafted request to the product. 2024-04-04 not yet calculated CVE-2024-29167
vultures@jpcert.or.jp tempesta — tempesta_fw
  Tempesta FW rate limits are not enabled by default. They are either set too large to capture empty CONTINUATION frames attacks or too small to handle normal HTTP requests appropriately. 2024-04-03 not yet calculated CVE-2024-2758
cret@cert.org
cret@cert.org tp-link — omada_er605
  TP-Link Omada ER605 DHCPv6 Client Options Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of TP-Link Omada ER605 routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within the handling of DHCP options. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-22420. 2024-04-01 not yet calculated CVE-2024-1179
zdi-disclosures@trendmicro.com tp-link — omada_er605
  TP-Link Omada ER605 Access Control Command Injection Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of TP-Link Omada ER605. Authentication is required to exploit this vulnerability. The specific issue exists within the handling of the name field in the access control user interface. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-22227. 2024-04-03 not yet calculated CVE-2024-1180
zdi-disclosures@trendmicro.com ubiquiti_inc — unifi_network_application
  A Command Injection vulnerability found in a Self-Hosted UniFi Network Servers (Linux) with UniFi Network Application (Version 8.0.28 and earlier) allows a malicious actor with UniFi Network Application Administrator credentials to escalate privileges to root on the host device. Affected Products: UniFi Network Application (Version 8.0.28 and earlier) . Mitigation: Update UniFi Network Application to Version 8.1.113 or later. 2024-04-04 not yet calculated CVE-2024-27981
support@hackerone.com unknown — gutenberg_blocks_by_kadence_blocks_
  The Gutenberg Blocks by Kadence Blocks WordPress plugin before 3.2.26 does not validate and escape some of its block options before outputting them back in a page/post where the block is embed, which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks 2024-04-05 not yet calculated CVE-2024-2509
contact@wpscan.com unknown — hubbub_lite_
  The Hubbub Lite WordPress plugin before 1.33.1 does not ensure that user have access to password protected post before displaying its content in a meta tag. 2024-04-01 not yet calculated CVE-2024-1526
contact@wpscan.com unknown — inline_related_posts
  The Inline Related Posts WordPress plugin before 3.5.0 does not sanitise and escape some of its settings, which could allow high privilege users such as Admin to perform Cross-Site Scripting attacks even when unfiltered_html is disallowed 2024-04-06 not yet calculated CVE-2024-2444
contact@wpscan.com unknown — my_calendar
  The My Calendar WordPress plugin before 3.4.24 does not sanitise and escape some parameters, which could allow users with a role as low as Subscriber to perform Cross-Site Scripting attacks (depending on the permissions set by the admin) 2024-04-02 not yet calculated CVE-2024-1274
contact@wpscan.com unknown — page_builder_gutenberg_blocks_
  The Page Builder Gutenberg Blocks WordPress plugin before 3.1.7 does not validate and escape some of its block options before outputting them back in a page/post where the block is embed, which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks 2024-04-02 not yet calculated CVE-2024-2369
contact@wpscan.com unknown — themify_
  Themify WordPress plugin before 1.4.4 does not have CSRF check in its bulk action, which could allow attackers to make logged in users delete arbitrary filters via CSRF attack, granted they know the related filter slugs 2024-04-01 not yet calculated CVE-2024-2262
contact@wpscan.com unknown — themify_
  Themify WordPress plugin before 1.4.4 does not sanitise and escape a parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin 2024-04-01 not yet calculated CVE-2024-2263
contact@wpscan.com unknown — themify_
  Themify WordPress plugin before 1.4.4 does not sanitise and escape some of its Filters 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-04-01 not yet calculated CVE-2024-2278
contact@wpscan.com unknown — woocommerce_cart_abandonment_recovery
  The WooCommerce Cart Abandonment Recovery WordPress plugin before 1.2.27 does not have CSRF check in its bulk actions, which could allow attackers to make logged in admins delete arbitrary email templates as well as delete and unsubscribe users from abandoned orders via CSRF attacks. 2024-04-03 not yet calculated CVE-2024-2322
contact@wpscan.com uvdesk — uvdesk/community-skeleton
  Improper Privilege Management in uvdesk/community-skeleton 2024-04-02 not yet calculated CVE-2024-3137
security@huntr.dev voltronic_power — viewpower_pro
  Voltronic Power ViewPower Pro Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Voltronic Power ViewPower Pro. Authentication is not required to exploit this vulnerability. The specific flaw exists within the RMI interface, which listens on TCP port 41009 by default. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-21012. 2024-04-01 not yet calculated CVE-2023-51570
zdi-disclosures@trendmicro.com voltronic_power — viewpower_pro
  Voltronic Power ViewPower Pro SocketService Missing Authentication Denial-of-Service Vulnerability. This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of Voltronic Power ViewPower Pro. Authentication is not required to exploit this vulnerability. The specific flaw exists within the SocketService module, which listens on UDP port 41222 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. Was ZDI-CAN-21162. 2024-04-01 not yet calculated CVE-2023-51571
zdi-disclosures@trendmicro.com voltronic_power — viewpower_pro
  Voltronic Power ViewPower Pro getMacAddressByIp Command Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Voltronic Power ViewPower Pro. Authentication is not required to exploit this vulnerability. The specific flaw exists within the getMacAddressByIP function. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-21163. 2024-04-01 not yet calculated CVE-2023-51572
zdi-disclosures@trendmicro.com voltronic_power — viewpower_pro
  Voltronic Power ViewPower Pro updateManagerPassword Exposed Dangerous Function Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on affected installations of Voltronic Power ViewPower Pro. Authentication is not required to exploit this vulnerability. The specific flaw exists within the updateManagerPassword function. The issue results from the exposure of a dangerous function. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-21203. 2024-04-01 not yet calculated CVE-2023-51573
zdi-disclosures@trendmicro.com N/A — N/A

 

Cross Site Scripting (XSS) vulnerability in ZoneMinder before version 1.34.21, allows remote attackers execute arbitrary code, escalate privileges, and obtain sensitive information via PHP_SELF component in classic/views/download.php. 2024-04-04 not yet calculated CVE-2020-25730
cve@mitre.org N/A — N/A

 

Server Side Request Forgery (SSRF) vulnerability in Gleez Cms 1.2.0, allows remote attackers to execute arbitrary code and obtain sensitive information via modules/gleez/classes/request.php. 2024-04-03 not yet calculated CVE-2021-27312
cve@mitre.org
cve@mitre.org N/A — N/A

 

A reflected cross-site scripting (XSS) vulnerability exists in the MT Safeline X-Ray X3310 webserver version NXG 19.05 that enables a remote attacker to execute JavaScript code and obtain sensitive information in a victim’s browser. 2024-04-04 not yet calculated CVE-2023-25199
cve@mitre.org N/A — N/A

 

An HTML injection vulnerability exists in the MT Safeline X-Ray X3310 webserver version NXG 19.05 that enables a remote attacker to render malicious HTML and obtain sensitive information in a victim’s browser. 2024-04-04 not yet calculated CVE-2023-25200
cve@mitre.org N/A — N/A

 

In VeridiumID before 3.5.0, the identity provider page allows an unauthenticated attacker to discover information about registered users via an LDAP injection attack. 2024-04-03 not yet calculated CVE-2023-44038
cve@mitre.org
cve@mitre.org N/A — N/A

 

In VeridiumID before 3.5.0, the WebAuthn API allows an internal unauthenticated attacker (who can pass enrollment verifications and is allowed to enroll a FIDO key) to register their FIDO authenticator to a victim’s account and consequently take over the account. 2024-04-03 not yet calculated CVE-2023-44039
cve@mitre.org
cve@mitre.org N/A — N/A

 

In VeridiumID before 3.5.0, the identity provider page is susceptible to a cross-site scripting (XSS) vulnerability that can be exploited by an internal unauthenticated attacker for JavaScript execution in the context of the user trying to authenticate. 2024-04-03 not yet calculated CVE-2023-44040
cve@mitre.org
cve@mitre.org N/A — N/A

 

In VeridiumID before 3.5.0, a stored cross-site scripting (XSS) vulnerability has been discovered in the admin portal that allows an authenticated attacker to take over all accounts by sending malicious input via the self-service portal. 2024-04-03 not yet calculated CVE-2023-45552
cve@mitre.org
cve@mitre.org N/A — N/A

 

Stack Overflow vulnerability in Btstack 1.6 and earlier allows attackers to cause a denial of service via crafted input to the char_for_nibble function. 2024-04-01 not yet calculated CVE-2023-48906
cve@mitre.org N/A — N/A

 

SpaceX Starlink Wi-Fi router Gen 2 before 2023.48.0 allows XSS via the ssid and password parameters on the Setup Page. 2024-04-05 not yet calculated CVE-2023-49965
cve@mitre.org N/A — N/A

 

LinuxServer.io Heimdall before 2.5.7 does not prevent use of icons that have non-image data such as the “<?php ?>” substring. 2024-04-01 not yet calculated CVE-2023-51803
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue in D-Link COVR 1100, 1102, 1103 AC1200 Dual-Band Whole-Home Mesh Wi-Fi System (Hardware Rev B1) truncates Wireless Access Point Passwords (WPA-PSK) allowing an attacker to gain unauthorized network access via weak authentication controls. 2024-04-03 not yet calculated CVE-2023-52043
cve@mitre.org N/A — N/A

 

SpaceX Starlink Wi-Fi router GEN 2 before 2023.53.0 and Starlink Dish before 07dd2798-ff15-4722-a9ee-de28928aed34 allow CSRF (e.g., for a reboot) via a DNS Rebinding attack. 2024-04-05 not yet calculated CVE-2023-52235
cve@mitre.org N/A — N/A

 

SheetJS Community Edition before 0.20.2 is vulnerable.to Regular Expression Denial of Service (ReDoS). 2024-04-05 not yet calculated CVE-2024-22363
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

Cross Site Scripting vulnerability in CA17 TeamsACS v.1.0.1 allows a remote attacker to execute arbitrary code via a crafted script to the errmsg parameter. 2024-04-02 not yet calculated CVE-2024-22780
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

Cross Site Scripting (XSS) vulnerability in Lime Survey Community Edition Version v.5.3.32+220817, allows remote attackers to execute arbitrary code via the Administrator email address parameter in the General Setting function. 2024-04-03 not yet calculated CVE-2024-24506
cve@mitre.org
cve@mitre.org N/A — N/A

 

Gibbon through 26.0.00 allows /modules/School%20Admin/messengerSettings.php Server Side Template Injection leading to Remote Code Execution because input is passed to the Twig template engine (messengerSettings.php) without sanitization. 2024-04-03 not yet calculated CVE-2024-24724
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in Softing uaToolkit Embedded before 1.41.1. When a subscription with a very low MaxNotificationPerPublish parameter is created, a publish response is mishandled, leading to memory consumption. When that happens often enough, the device will be out of memory, i.e., a denial of service. 2024-04-02 not yet calculated CVE-2024-25075
cve@mitre.org N/A — N/A

 

WebMail in Axigen 10.x before 10.3.3.62 allows XSS via the image attachment viewer. 2024-04-01 not yet calculated CVE-2024-25080
cve@mitre.org
cve@mitre.org N/A — N/A

 

Server Side Request Forgery (SSRF) vulnerability in 71cms v1.0.0, allows remote unauthenticated attackers to obtain sensitive information via getweather.html. 2024-04-02 not yet calculated CVE-2024-25187
cve@mitre.org
cve@mitre.org N/A — N/A

 

Cross Site Scripting (XSS) vulnerability in Advanced REST Client v.17.0.9 allows a remote attacker to execute arbitrary code and obtain sensitive information via a crafted script to the edit details parameter of the New Project function. 2024-04-04 not yet calculated CVE-2024-25503
cve@mitre.org N/A — N/A

 

Server Side Request Forgery (SSRF) vulnerability in Friendica versions after v.2023.12, allows a remote attacker to execute arbitrary code and obtain sensitive information via the fpostit.php component. 2024-04-03 not yet calculated CVE-2024-25864
cve@mitre.org N/A — N/A

 

Chilkat before v9.5.0.98, allows attackers to obtain sensitive information via predictable PRNG in ChilkatRand::randomBytes function. 2024-04-05 not yet calculated CVE-2024-26329
cve@mitre.org N/A — N/A

 

Cross Site Scripting (XSS) vulnerability in Friendica versions after v.2023.12, allows a remote attacker to execute arbitrary code and obtain sensitive information via the BBCode tags in the post content and post comments function. 2024-04-03 not yet calculated CVE-2024-26495
cve@mitre.org N/A — N/A

 

MailDev 2 through 2.1.0 allows Remote Code Execution via a crafted Content-ID header for an e-mail attachment, leading to lib/mailserver.js writing arbitrary code into the routes.js file. 2024-04-05 not yet calculated CVE-2024-27448
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

INOTEC Sicherheitstechnik WebServer CPS220/64 3.3.19 allows a remote attacker to read arbitrary files via absolute path traversal, such as with the /cgi-bin/display?file=/etc/passwd URI. 2024-04-04 not yet calculated CVE-2024-27575
cve@mitre.org
cve@mitre.org N/A — N/A

 

Alldata V0.4.6 is vulnerable to Incorrect Access Control. A total of many modules interface documents have been leaked.For example, the /api/system/v2/api-docs module. 2024-04-02 not yet calculated CVE-2024-27602
cve@mitre.org N/A — N/A

 

Alldata V0.4.6 is vulnerable to Command execution vulnerability. System commands can be deserialized. 2024-04-02 not yet calculated CVE-2024-27604
cve@mitre.org N/A — N/A

 

Alldata V0.4.6 is vulnerable to Insecure Permissions. Using users (test) can query information about the users in the system. 2024-04-02 not yet calculated CVE-2024-27605
cve@mitre.org N/A — N/A

 

Bonita before 2023.2-u2 allows stored XSS via a UI screen in the administration panel. 2024-04-01 not yet calculated CVE-2024-27609
cve@mitre.org N/A — N/A

 

An issue in Ladder v.0.0.1 thru v.0.0.21 allows a remote attacker to obtain sensitive information via a crafted request to the API. 2024-04-06 not yet calculated CVE-2024-27620
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

Macro Expert through 4.9.4 allows BUILTINUsers:(OI)(CI)(M) access to the “%PROGRAMFILES(X86)%GrassSoftMacro Expert” folder and thus an unprivileged user can escalate to SYSTEM by replacing the MacroService.exe binary. 2024-04-03 not yet calculated CVE-2024-27674
cve@mitre.org
cve@mitre.org N/A — N/A

 

Cross Site Scripting vulnerability in Leantime v3.0.6 allows attackers to execute arbitrary code via upload of crafted PDF file to the files/browse endpoint. 2024-04-03 not yet calculated CVE-2024-27705
cve@mitre.org N/A — N/A

 

Cross Site Scripting vulnerability in Huly Platform v.0.6.202 allows attackers to execute arbitrary code via upload of crafted SVG file to issues. 2024-04-03 not yet calculated CVE-2024-27706
cve@mitre.org N/A — N/A

 

In Unify CP IP Phone firmware 1.10.4.3, files are not encrypted and contain sensitive information such as the root password hash. 2024-04-05 not yet calculated CVE-2024-28065
cve@mitre.org
cve@mitre.org N/A — N/A

 

Puwell Cloud Tech Co, Ltd 360Eyes Pro v3.9.5.16(3090516) was discovered to transmit sensitive information in cleartext. This vulnerability allows attackers to intercept and access sensitive information, including users’ credentials and password change requests. 2024-04-03 not yet calculated CVE-2024-28275
cve@mitre.org
cve@mitre.org N/A — N/A

 

A DOM-based open redirection in the returnUrl parameter of INSTINCT UI Web Client 6.5.0 allows attackers to redirect users to malicious sites via a crafted URL. 2024-04-02 not yet calculated CVE-2024-28287
cve@mitre.org N/A — N/A

 

Buffer Overflow vulnerability in CSAPP_Lab CSAPP Lab3 15-213 Fall 20xx allows a remote attacker to execute arbitrary code via the lab3 of csapp,lab3/buflab-update.pl component. 2024-04-03 not yet calculated CVE-2024-28515
cve@mitre.org
cve@mitre.org N/A — N/A

 

File Upload vulnerability in Byzoro Networks Smart multi-service security gateway intelligent management platform version S210, allows an attacker to obtain sensitive information via the uploadfile.php component. 2024-04-04 not yet calculated CVE-2024-28520
cve@mitre.org N/A — N/A

 

An issue was discovered in Axigen Mail Server for Windows versions 10.5.18 and before, allows local low-privileged attackers to execute arbitrary code and escalate privileges via insecure DLL loading from a world-writable directory during service initialization. 2024-04-03 not yet calculated CVE-2024-28589
cve@mitre.org N/A — N/A

 

Cross Site Scripting vulnerability in EginDemirbilek NorthStar C2 v1 allows a remote attacker to execute arbitrary code via the login.php component. 2024-04-06 not yet calculated CVE-2024-28741
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in Mbed TLS 3.5.x before 3.6.0. When an SSL context was reset with the mbedtls_ssl_session_reset() API, the maximum TLS version to be negotiated was not restored to the configured one. An attacker was able to prevent an Mbed TLS server from establishing any TLS 1.3 connection, potentially resulting in a Denial of Service or forced version downgrade from TLS 1.3 to TLS 1.2. 2024-04-03 not yet calculated CVE-2024-28755
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in Mbed TLS 3.5.x before 3.6.0. When negotiating the TLS version on the server side, it can fall back to the TLS 1.2 implementation of the protocol if it is disabled. If the TLS 1.2 implementation was disabled at build time, a TLS 1.2 client could put a TLS 1.3-only server into an infinite loop processing a TLS 1.2 ClientHello, resulting in a denial of service. If the TLS 1.2 implementation was disabled at runtime, a TLS 1.2 client can successfully establish a TLS 1.2 connection with the server. 2024-04-03 not yet calculated CVE-2024-28836
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in seeyonOA version 8, allows remote attackers to execute arbitrary code via the importProcess method in WorkFlowDesignerController.class component. 2024-04-02 not yet calculated CVE-2024-29276
cve@mitre.org N/A — N/A

 

CSV Injection vulnerability in Addactis IBNRS v.3.10.3.107 allows a remote attacker to execute arbitrary code via a crafted .ibnrs file to the Project Description, Identifiers, Custom Triangle Name (inside Input Triangles) and Yield Curve Name parameters. 2024-04-04 not yet calculated CVE-2024-29375
cve@mitre.org N/A — N/A

 

projeqtor up to 11.2.0 was discovered to contain a SQL injection vulnerability via the component /view/criticalResourceExport.php. 2024-04-04 not yet calculated CVE-2024-29386
cve@mitre.org N/A — N/A

 

projeqtor up to 11.2.0 was discovered to contain a remote code execution (RCE) vulnerability via the component /view/print.php. 2024-04-04 not yet calculated CVE-2024-29387
cve@mitre.org N/A — N/A

 

Cross Site Scripting vulnerability in Webasyst v.2.9.9 allows a remote attacker to run arbitrary code via the Instant messenger field in the Contact info function. 2024-04-03 not yet calculated CVE-2024-29413
cve@mitre.org N/A — N/A

 

Alldata v0.4.6 was discovered to contain a SQL injection vulnerability via the tablename parameter at /data/masterdata/datas. 2024-04-02 not yet calculated CVE-2024-29432
cve@mitre.org
cve@mitre.org N/A — N/A

 

A deserialization vulnerability in the FASTJSON component of Alldata v0.4.6 allows attackers to execute arbitrary commands via supplying crafted data. 2024-04-01 not yet calculated CVE-2024-29433
cve@mitre.org N/A — N/A

 

An issue in the system image upload interface of Alldata v0.4.6 allows attackers to execute a directory traversal when uploading a file. 2024-04-02 not yet calculated CVE-2024-29434
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue discovered in Alldata v0.4.6 allows attacker to run arbitrary commands via the processId parameter. 2024-04-01 not yet calculated CVE-2024-29435
cve@mitre.org N/A — N/A

 

Lack of sanitization during Installation Process in Dolibarr ERP CRM up to version 19.0.0 allows an attacker with adjacent access to the network to execute arbitrary code via a specifically crafted input. 2024-04-03 not yet calculated CVE-2024-29477
cve@mitre.org
cve@mitre.org N/A — N/A

 

File Upload vulnerability in lepton v.7.1.0 allows a remote authenticated attackers to execute arbitrary code via uploading a crafted PHP file. 2024-04-02 not yet calculated CVE-2024-29514
cve@mitre.org N/A — N/A

 

A race condition in the installer executable in Qlik Qlikview before versions May 2022 SR3 (12.70.20300) and May 2023 SR2 (12,80.20200) may allow an existing lower privileged user to cause code to be executed in the context of a Windows Administrator. 2024-04-05 not yet calculated CVE-2024-29863
cve@mitre.org N/A — N/A

 

In Mbed TLS 3.3.0 through 3.5.2 before 3.6.0, a malicious client can cause information disclosure or a denial of service because of a stack buffer over-read (of less than 256 bytes) in a TLS 1.3 server via a TLS 3.1 ClientHello. 2024-04-03 not yet calculated CVE-2024-30166
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in SeaCMS version 12.9, allows remote attackers to execute arbitrary code via admin notify.php. 2024-04-04 not yet calculated CVE-2024-30565
cve@mitre.org N/A — N/A

 

Netgear R6850 1.1.0.88 was discovered to contain a command injection vulnerability via the c4-IPAddr parameter. 2024-04-03 not yet calculated CVE-2024-30568
cve@mitre.org
cve@mitre.org N/A — N/A

 

An information leak in currentsetting.htm of Netgear R6850 v1.1.0.88 allows attackers to obtain sensitive information without any authentication required. 2024-04-03 not yet calculated CVE-2024-30569
cve@mitre.org
cve@mitre.org N/A — N/A

 

An information leak in debuginfo.htm of Netgear R6850 v1.1.0.88 allows attackers to obtain sensitive information without any authentication required. 2024-04-03 not yet calculated CVE-2024-30570
cve@mitre.org
cve@mitre.org N/A — N/A

 

An information leak in the BRS_top.html component of Netgear R6850 v1.1.0.88 allows attackers to obtain sensitive information without any authentication required. 2024-04-03 not yet calculated CVE-2024-30571
cve@mitre.org
cve@mitre.org N/A — N/A

 

Netgear R6850 1.1.0.88 was discovered to contain a command injection vulnerability via the ntp_server parameter. 2024-04-03 not yet calculated CVE-2024-30572
cve@mitre.org
cve@mitre.org N/A — N/A

 

Tenda AX1803 v1.0.0.1 contains a stack overflow via the serviceName parameter in the function fromAdvSetMacMtuWan. 2024-04-02 not yet calculated CVE-2024-30620
cve@mitre.org N/A — N/A

 

Tenda AX1803 v1.0.0.1 contains a stack overflow via the serverName parameter in the function fromAdvSetMacMtuWan. 2024-04-02 not yet calculated CVE-2024-30621
cve@mitre.org N/A — N/A

 

An issue was discovered in Bento4 v1.6.0-641-2-g1529b83. There is a heap overflow in AP4_Dec3Atom::AP4_Dec3Atom at Ap4Dec3Atom.cpp, leading to a Denial of Service (DoS), as demonstrated by mp42aac. 2024-04-02 not yet calculated CVE-2024-30806
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in Bento4 v1.6.0-641-2-g1529b83. There is a heap-use-after-free in AP4_UnknownAtom::~AP4_UnknownAtom at Ap4Atom.cpp, leading to a Denial of Service (DoS), as demonstrated by mp42ts. 2024-04-02 not yet calculated CVE-2024-30807
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in Bento4 v1.6.0-641-2-g1529b83. There is a heap-use-after-free in AP4_SubStream::~AP4_SubStream at Ap4ByteStream.cpp, leading to a Denial of Service (DoS), as demonstrated by mp42ts. 2024-04-02 not yet calculated CVE-2024-30808
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in Bento4 v1.6.0-641-2-g1529b83. There is a heap-use-after-free in Ap4Sample.h in AP4_Sample::GetOffset() const, leading to a Denial of Service (DoS), as demonstrated by mp42ts. 2024-04-02 not yet calculated CVE-2024-30809
cve@mitre.org
cve@mitre.org N/A — N/A

 

Arbitrary file upload vulnerability in Sourcecodester Complete E-Commerce Site v1.0, allows remote attackers to execute arbitrary code via filename parameter in admin/products_photo.php. 2024-04-05 not yet calculated CVE-2024-30849
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/edit_fire_wall.php. 2024-04-01 not yet calculated CVE-2024-30858
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/config_ISCGroupSSLCert.php. 2024-04-01 not yet calculated CVE-2024-30859
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/export_excel_user.php. 2024-04-01 not yet calculated CVE-2024-30860
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/configguide/ipsec_guide_1.php. 2024-04-01 not yet calculated CVE-2024-30861
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /3g/index.php. 2024-04-01 not yet calculated CVE-2024-30862
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /WebPages/history.php. 2024-04-01 not yet calculated CVE-2024-30863
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/config_ISCGroupTimePolicy.php. 2024-04-01 not yet calculated CVE-2024-30864
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/edit_user_login.php. 2024-04-01 not yet calculated CVE-2024-30865
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /3g/menu.php. 2024-04-01 not yet calculated CVE-2024-30866
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/edit_virtual_site_info.php. 2024-04-01 not yet calculated CVE-2024-30867
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/add_getlogin.php. 2024-04-01 not yet calculated CVE-2024-30868
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /admin/address_interpret.php. 2024-04-01 not yet calculated CVE-2024-30870
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /WebPages/applyhardware.php. 2024-04-01 not yet calculated CVE-2024-30871
cve@mitre.org N/A — N/A

 

netentsec NS-ASG 6.3 is vulnerable to SQL Injection via /include/authrp.php. 2024-04-01 not yet calculated CVE-2024-30872
cve@mitre.org N/A — N/A

 

A command injection vulnerability exists in /goform/exeCommand in Tenda AC18 v15.03.05.05, which allows attackers to construct cmdinput parameters for arbitrary command execution. 2024-04-05 not yet calculated CVE-2024-30891
cve@mitre.org N/A — N/A

 

DedeCMS v5.7 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /src/dede/co_do.php. 2024-04-02 not yet calculated CVE-2024-30946
cve@mitre.org N/A — N/A

 

DedeCMS v5.7 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /src/dede/member_scores.php. 2024-04-02 not yet calculated CVE-2024-30965
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue in Secnet Security Network Intelligent AC Management System v.1.02.040 allows a local attacker to escalate privileges via the password component. 2024-04-05 not yet calculated CVE-2024-30977
cve@mitre.org
cve@mitre.org N/A — N/A

 

SQL Injection vulnerability in PHPGurukul Men Salon Management System v.2.0, allows remote attackers to execute arbitrary code and obtain sensitive information via the email parameter in the index.php component. 2024-04-03 not yet calculated CVE-2024-30998
cve@mitre.org N/A — N/A

 

Buffer Overflow vulnerability in Bento4 Bento v.1.6.0-641 allows a remote attacker to execute arbitrary code via the AP4 BitReader::ReadCache() at Ap4Utils.cpp component. 2024-04-02 not yet calculated CVE-2024-31002
cve@mitre.org
cve@mitre.org N/A — N/A

 

Buffer Overflow vulnerability in Bento4 Bento v.1.6.0-641 allows a remote attacker to execute arbitrary code via the AP4_MemoryByteStream::WritePartial at Ap4ByteStream.cpp. 2024-04-02 not yet calculated CVE-2024-31003
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue in Bento4 Bento v.1.6.0-641 allows a remote attacker to execute arbitrary code via the Ap4StsdAtom.cpp,AP4_StsdAtom::AP4_StsdAtom,mp4fragment. 2024-04-02 not yet calculated CVE-2024-31004
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue in Bento4 Bento v.1.6.0-641 allows a remote attacker to execute arbitrary code via the Ap4MdhdAtom.cpp,AP4_MdhdAtom::AP4_MdhdAtom,mp4fragment 2024-04-02 not yet calculated CVE-2024-31005
cve@mitre.org
cve@mitre.org N/A — N/A

 

An issue was discovered in WUZHICMS version 4.1.0, allows an attacker to execute arbitrary code and obtain sensitive information via the index.php file. 2024-04-03 not yet calculated CVE-2024-31008
cve@mitre.org N/A — N/A

 

SQL injection vulnerability in SEMCMS v.4.8, allows a remote attacker to obtain sensitive information via lgid parameter in Banner.php. 2024-04-03 not yet calculated CVE-2024-31009
cve@mitre.org N/A — N/A

 

SQL injection vulnerability in SEMCMS v.4.8, allows a remote attacker to obtain sensitive information via the ID parameter in Banner.php. 2024-04-03 not yet calculated CVE-2024-31010
cve@mitre.org N/A — N/A

 

Arbitrary file write vulnerability in beescms v.4.0, allows a remote attacker to execute arbitrary code via a file path that was not isolated and the suffix was not verified in admin_template.php. 2024-04-03 not yet calculated CVE-2024-31011
cve@mitre.org N/A — N/A

 

An issue was discovered in SEMCMS v.4.8, allows remote attackers to execute arbitrary code, escalate privileges, and obtain sensitive information via the upload.php file. 2024-04-03 not yet calculated CVE-2024-31012
cve@mitre.org N/A — N/A

 

Cross Site Scripting (XSS) vulnerability in emlog version Pro 2.3, allow remote attackers to execute arbitrary code via a crafted payload to the bottom of the homepage in footer_info parameter. 2024-04-03 not yet calculated CVE-2024-31013
cve@mitre.org N/A — N/A

 

SQL Injection vulnerability in ECshop 4.x allows an attacker to obtain sensitive information via the file/article.php component. 2024-04-04 not yet calculated CVE-2024-31025
cve@mitre.org N/A — N/A

 

JJWT (aka Java JWT) through 0.12.5 ignores certain characters and thus a user might falsely conclude that they have a strong key. The impacted code is the setSigningKey() method within the DefaultJwtParser class and the signWith() method within the DefaultJwtBuilder class. NOTE: the vendor disputes this because the “ignores” behavior cannot occur (in any version) unless there is a user error in how JJWT is used, and because the version that was actually tested must have been more than six years out of date. 2024-04-01 not yet calculated CVE-2024-31033
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A

 

Yubico ykman-gui (aka YubiKey Manager GUI) before 1.2.6 on Windows, when Edge is not used, allows privilege escalation because browser windows can open as Administrator. 2024-04-04 not yet calculated CVE-2024-31498
cve@mitre.org N/A — N/A

 

LLVM before 18.1.3 generates code in which the LR register can be overwritten without data being saved to the stack, and thus there can sometimes be an exploitable error in the flow of control. This affects the ARM backend and can be demonstrated with Clang. NOTE: the vendor perspective is “we don’t have strong objections for a CVE to be created … It does seem that the likelihood of this miscompile enabling an exploit remains very low, because the miscompile resulting in this JOP gadget is such that the function is most likely to crash on most valid inputs to the function. So, if this function is covered by any testing, the miscompile is most likely to be discovered before the binary is shipped to production.” 2024-04-05 not yet calculated CVE-2024-31852
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org