Linux Distros Unpatched Vulnerability : CVE-2024-49993

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
##

include('compat.inc');

if (description)
{
  script_id(230857);
  script_version("1.1");
  script_set_attribute(attribute:"plugin_modification_date", value:"2025/03/06");

  script_cve_id("CVE-2024-49993");

  script_name(english:"Linux Distros Unpatched Vulnerability : CVE-2024-49993");

  script_set_attribute(attribute:"synopsis", value:
"The Linux/Unix host has one or more packages installed with a vulnerability that the vendor indicates will not be
patched.");
  script_set_attribute(attribute:"description", value:
"The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied
patch available.

  - In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential lockup if
    qi_submit_sync called with 0 count If qi_submit_sync() is invoked with 0 invalidation descriptors (for
    instance, for DMA draining purposes), we can run into a bug where a submitting thread fails to detect the
    completion of invalidation_wait. Subsequently, this led to a soft lockup. Currently, there is no impact by
    this bug on the existing users because no callers are submitting invalidations with 0 descriptors. This
    fix will enable future users (such as DMA drain) calling qi_submit_sync() with 0 count. Suppose thread T1
    invokes qi_submit_sync() with non-zero descriptors, while concurrently, thread T2 calls qi_submit_sync()
    with zero descriptors. Both threads then enter a while loop, waiting for their respective descriptors to
    complete. T1 detects its completion (i.e., T1's invalidation_wait status changes to QI_DONE by HW) and
    proceeds to call reclaim_free_desc() to reclaim all descriptors, potentially including adjacent ones of
    other threads that are also marked as QI_DONE. During this time, while T2 is waiting to acquire the
    qi->q_lock, the IOMMU hardware may complete the invalidation for T2, setting its status to QI_DONE.
    However, if T1's execution of reclaim_free_desc() frees T2's invalidation_wait descriptor and changes its
    status to QI_FREE, T2 will not observe the QI_DONE status for its invalidation_wait and will indefinitely
    remain stuck. This soft lockup does not occur when only non-zero descriptors are submitted.In such cases,
    invalidation descriptors are interspersed among wait descriptors with the status QI_IN_USE, acting as
    barriers. These barriers prevent the reclaim code from mistakenly freeing descriptors belonging to other
    submitters. Considered the following example timeline: T1 T2 ======================================== ID1
    WD1 while(WD1!=QI_DONE) unlock lock WD1=QI_DONE* WD2 while(WD2!=QI_DONE) unlock lock WD1==QI_DONE?
    ID1=QI_DONE WD2=DONE* reclaim() ID1=FREE WD1=FREE WD2=FREE unlock soft lockup! T2 never sees QI_DONE in
    WD2 Where: ID = invalidation descriptor WD = wait descriptor * Written by hardware The root of the problem
    is that the descriptor status QI_DONE flag is used for two conflicting purposes: 1. signal a descriptor is
    ready for reclaim (to be freed) 2. signal by the hardware that a wait descriptor is complete The solution
    (in this patch) is state separation by using QI_FREE flag for #1. Once a thread's invalidation descriptors
    are complete, their status would be set to QI_FREE. The reclaim_free_desc() function would then only free
    descriptors marked as QI_FREE instead of those marked as QI_DONE. This change ensures that T2 (from the
    previous example) will correctly observe the completion of its invalidation_wait (marked as QI_DONE).
    (CVE-2024-49993)

Note that Nessus relies on the presence of the package as reported by the vendor.");
  script_set_attribute(attribute:"solution", value:
"There is no known solution at this time.");
  script_set_attribute(attribute:"agent", value:"unix");
  script_set_cvss_base_vector("CVSS2#AV:L/AC:H/Au:N/C:P/I:N/A:P");
  script_set_cvss_temporal_vector("CVSS2#E:U/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:U/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2024-49993");

  script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"false");
  script_set_attribute(attribute:"vendor_unpatched", value:"true");

  script_set_attribute(attribute:"vuln_publication_date", value:"2024/10/21");
  script_set_attribute(attribute:"plugin_publication_date", value:"2025/03/06");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"Misc.");

  script_copyright(english:"This script is Copyright (C) 2025 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("ssh_get_info2.nasl");
  script_require_keys("Host/cpu", "Host/local_checks_enabled", "global_settings/vendor_unpatched");
  script_require_ports("Host/RedHat/release", "Host/RedHat/rpm-list");

  exit(0);
}
include('vdf.inc');

# @tvdl-content
var vuln_data = {
 "metadata": {
  "spec_version": "1.0p"
 },
 "requires": [
  {
   "scope": "scan_config",
   "match": {
    "vendor_unpatched": true
   }
  },
  {
   "scope": "target",
   "match": {
    "os": "linux"
   }
  }
 ],
 "report": {
  "report_type": "unpatched"
 },
 "checks": [
  {
   "product": {
    "name": [
     "kernel",
     "kernel-rt"
    ],
    "type": "rpm_package"
   },
   "check_algorithm": "rpm",
   "constraints": [
    {
     "requires": [
      {
       "scope": "target",
       "match": {
        "distro": "redhat"
       }
      },
      {
       "scope": "target",
       "match_one": {
        "os_version": [
         "8",
         "9"
        ]
       }
      }
     ]
    }
   ]
  }
 ]
};

var vdf_res = vdf::check_and_report(vuln_data:vuln_data, severity:SECURITY_NOTE);
vdf::handle_check_and_report_errors(vdf_result: vdf_res);