CVE-2021-47366 (GCVE-0-2021-47366)

Vulnerability from cvelistv5 – Published: 2024-05-21 15:03 – Updated: 2026-08-05 08:47
VLAI
Title
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
Summary
In the Linux kernel, the following vulnerability has been resolved: afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value. This is a problem, however, since the file position and length fields of FS.FetchData are *signed* 32-bit values. Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values. This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that. Note that the issue does not exist with FS.StoreData - that uses *unsigned* 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values. This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client[1]. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like: error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index This can be observed in the server's FileLog with something like the following appearing: Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5 Note the file position of 18446744071815340032. This is the requested file position sign-extended.
Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: b9b1f8d5930a813879278d0cbfc8c658d6a038dc , < e66fc460d6dcf85cf12288e133a081205aebcd97 (git)
Affected: b9b1f8d5930a813879278d0cbfc8c658d6a038dc , < b537a3c21775075395af475dcc6ef212fcf29db8 (git)
Create a notification for this product.
Linux Linux Affected: 2.6.22
Unaffected: 0 , < 2.6.22 (semver)
Unaffected: 5.14.9 , ≤ 5.14.* (semver)
Unaffected: 5.15 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2021-47366",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-06-17T17:37:26.717348Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-17T17:38:20.276Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-04T05:32:08.615Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/afs/fs_probe.c",
            "fs/afs/fsclient.c",
            "fs/afs/internal.h",
            "fs/afs/protocol_afs.h",
            "fs/afs/protocol_yfs.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "e66fc460d6dcf85cf12288e133a081205aebcd97",
              "status": "affected",
              "version": "b9b1f8d5930a813879278d0cbfc8c658d6a038dc",
              "versionType": "git"
            },
            {
              "lessThan": "b537a3c21775075395af475dcc6ef212fcf29db8",
              "status": "affected",
              "version": "b9b1f8d5930a813879278d0cbfc8c658d6a038dc",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/afs/fs_probe.c",
            "fs/afs/fsclient.c",
            "fs/afs/internal.h",
            "fs/afs/protocol_afs.h",
            "fs/afs/protocol_yfs.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.22"
            },
            {
              "lessThan": "2.6.22",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.14.*",
              "status": "unaffected",
              "version": "5.14.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "5.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.14.9",
                  "versionStartIncluding": "2.6.22",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15",
                  "versionStartIncluding": "2.6.22",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\n\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\nLinux\u0027s afs client switches between them when talking to a non-YFS server\nif the read size, the file position or the sum of the two have the upper 32\nbits set of the 64-bit value.\n\nThis is a problem, however, since the file position and length fields of\nFS.FetchData are *signed* 32-bit values.\n\nFix this by capturing the capability bits obtained from the fileserver when\nit\u0027s sent an FS.GetCapabilities RPC, rather than just discarding them, and\nthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\nswitch on the parameter values.\n\nThis capabilities flag could also be used to limit the maximum size of the\nfile, but all servers must be checked for that.\n\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\n32-bit values.  It\u0027s also not a problem with Auristor servers as its\nYFS.FetchData64 op uses unsigned 64-bit values.\n\nThis can be tested by cloning a git repo through an OpenAFS client to an\nOpenAFS server and then doing \"git status\" on it from a Linux afs\nclient[1].  Provided the clone has a pack file that\u0027s in the 2G-4G range,\nthe git status will show errors like:\n\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\nThis can be observed in the server\u0027s FileLog with something like the\nfollowing appearing:\n\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\n...\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\n\nNote the file position of 18446744071815340032.  This is the requested file\nposition sign-extended."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The bug is in the kAFS client fetch path, reached via local read/page-cache I/O on an afs-mounted file (read_iter \u2192 afs_issue_read \u2192 afs_fs_fetch_data), not via unsolicited remote packet processing.\nAC:L - An attacker who can read a file at offsets in the 2G-4G range against a non-YFS OpenAFS server triggers the wrong FS.FetchData RPC reliably; no race or uncontrolled memory layout is required.\nPR:L - Triggering requires only an unprivileged local user able to open/read files on an already-mounted AFS volume (anonymous or user RxRPC key); CAP_SYS_ADMIN is needed to mount, but not to exercise the vulnerable read path.\nUI:N - No separate victim action is required; the attacker initiates the read themselves, and AFS being mounted is an environmental precondition rather than user interaction.\nS:U - Impact stays within normal kernel/filesystem behavior for the client (and collateral OpenAFS volume availability); there is no VM escape, sandbox escape, or other security-authority boundary cross.\nC:N - The sign-extended position falls past EOF so the server returns an error rather than file data, and there is no kernel memory disclosure or other information leak.\nI:H - The vulnerability is documented as read-data corruption (wrong/untrustworthy file contents in the 2G-4G range, e.g. git packfile mismatches), so integrity of returned file data is fully lost for affected regions.\nA:H - Affected reads fail with remote I/O errors, and reproducers show the bad FetchData RPCs can take the OpenAFS volume offline for salvage, denying access to the shared volume."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T08:47:28.087Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97"
        },
        {
          "url": "https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8"
        }
      ],
      "title": "afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2021-47366",
    "datePublished": "2024-05-21T15:03:33.176Z",
    "dateReserved": "2024-05-21T14:58:30.810Z",
    "dateUpdated": "2026-08-05T08:47:28.087Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2021-47366",
      "date": "2026-08-10",
      "epss": "0.00211",
      "percentile": "0.11422"
    },
    "fkie_nvd": {
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\\n\\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\\nLinux\u0027s afs client switches between them when talking to a non-YFS server\\nif the read size, the file position or the sum of the two have the upper 32\\nbits set of the 64-bit value.\\n\\nThis is a problem, however, since the file position and length fields of\\nFS.FetchData are *signed* 32-bit values.\\n\\nFix this by capturing the capability bits obtained from the fileserver when\\nit\u0027s sent an FS.GetCapabilities RPC, rather than just discarding them, and\\nthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be\\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\\nswitch on the parameter values.\\n\\nThis capabilities flag could also be used to limit the maximum size of the\\nfile, but all servers must be checked for that.\\n\\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\\n32-bit values.  It\u0027s also not a problem with Auristor servers as its\\nYFS.FetchData64 op uses unsigned 64-bit values.\\n\\nThis can be tested by cloning a git repo through an OpenAFS client to an\\nOpenAFS server and then doing \\\"git status\\\" on it from a Linux afs\\nclient[1].  Provided the clone has a pack file that\u0027s in the 2G-4G range,\\nthe git status will show errors like:\\n\\n\\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\\n\\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\\n\\nThis can be observed in the server\u0027s FileLog with something like the\\nfollowing appearing:\\n\\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\\n...\\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\\n\\nNote the file position of 18446744071815340032.  This is the requested file\\nposition sign-extended.\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se resolvi\\u00f3 la siguiente vulnerabilidad: afs: corrige la corrupci\\u00f3n en las lecturas en fpos 2G-4G desde un servidor OpenAFS. AFS-3 tiene dos variantes RPC de recuperaci\\u00f3n de datos, FS.FetchData y FS.FetchData64, y conmutadores de cliente afs de Linux. entre ellos cuando se habla con un servidor que no es YFS si el tama\\u00f1o de lectura, la posici\\u00f3n del archivo o la suma de los dos tienen los 32 bits superiores establecidos del valor de 64 bits. Sin embargo, esto es un problema, ya que los campos de posici\\u00f3n y longitud del archivo de FS.FetchData son valores *firmados* de 32 bits. Solucione este problema capturando los bits de capacidad obtenidos del servidor de archivos cuando se env\\u00eda un RPC FS.GetCapabilities, en lugar de simplemente descartarlos, y luego seleccionando el indicador VICED_CAPABILITY_64BITFILES. Esto luego se puede usar para decidir si usar FS.FetchData o FS.FetchData64, y tambi\\u00e9n FS.StoreData o FS.StoreData64, en lugar de usar Upper_32_bits() para activar los valores de los par\\u00e1metros. Este indicador de capacidades tambi\\u00e9n podr\\u00eda usarse para limitar el tama\\u00f1o m\\u00e1ximo del archivo, pero se deben verificar todos los servidores para eso. Tenga en cuenta que el problema no existe con FS.StoreData, que utiliza valores de 32 bits *sin firmar*. Tampoco es un problema con los servidores Auristor ya que su operaci\\u00f3n YFS.FetchData64 utiliza valores de 64 bits sin firmar. Esto se puede probar clonando un repositorio de git a trav\\u00e9s de un cliente OpenAFS en un servidor OpenAFS y luego ejecutando el \\\"estado de git\\\" desde un cliente afs de Linux[1]. Siempre que el clon tenga un archivo de paquete que est\\u00e9 en el rango 2G-4G, el estado de git mostrar\\u00e1 errores como: error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack no coincide con el \\u00edndice error: packfile .git/objects/ pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack no coincide con el \\u00edndice. Esto se puede observar en el FileLog del servidor y aparece algo como lo siguiente: Dom 29 de agosto 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114 , Anfitri\\u00f3n 192.168.11.201:7001, Id 1001 dom 29 de agosto 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 dom 29 de agosto 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 dom 29 de agosto 19:3 1:39 2021 FetchData_RXStyle: tama\\u00f1o de archivo 2400758866 ... domingo 29 de agosto 19:31:40 2021 SRXAFS_FetchData devuelve 5 Tenga en cuenta la posici\\u00f3n del archivo de 18446744071815340032. Esta es la posici\\u00f3n del archivo solicitada con signo extendido.\"}]",
      "id": "CVE-2021-47366",
      "lastModified": "2024-11-21T06:35:59.473",
      "published": "2024-05-21T15:15:22.633",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Awaiting Analysis"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2021-47366\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-21T15:15:22.633\",\"lastModified\":\"2026-08-04T10:16:59.990\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\\n\\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\\nLinux\u0027s afs client switches between them when talking to a non-YFS server\\nif the read size, the file position or the sum of the two have the upper 32\\nbits set of the 64-bit value.\\n\\nThis is a problem, however, since the file position and length fields of\\nFS.FetchData are *signed* 32-bit values.\\n\\nFix this by capturing the capability bits obtained from the fileserver when\\nit\u0027s sent an FS.GetCapabilities RPC, rather than just discarding them, and\\nthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be\\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\\nswitch on the parameter values.\\n\\nThis capabilities flag could also be used to limit the maximum size of the\\nfile, but all servers must be checked for that.\\n\\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\\n32-bit values.  It\u0027s also not a problem with Auristor servers as its\\nYFS.FetchData64 op uses unsigned 64-bit values.\\n\\nThis can be tested by cloning a git repo through an OpenAFS client to an\\nOpenAFS server and then doing \\\"git status\\\" on it from a Linux afs\\nclient[1].  Provided the clone has a pack file that\u0027s in the 2G-4G range,\\nthe git status will show errors like:\\n\\n\\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\\n\\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\\n\\nThis can be observed in the server\u0027s FileLog with something like the\\nfollowing appearing:\\n\\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\\n...\\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\\n\\nNote the file position of 18446744071815340032.  This is the requested file\\nposition sign-extended.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: afs: corrige la corrupci\u00f3n en las lecturas en fpos 2G-4G desde un servidor OpenAFS. AFS-3 tiene dos variantes RPC de recuperaci\u00f3n de datos, FS.FetchData y FS.FetchData64, y conmutadores de cliente afs de Linux. entre ellos cuando se habla con un servidor que no es YFS si el tama\u00f1o de lectura, la posici\u00f3n del archivo o la suma de los dos tienen los 32 bits superiores establecidos del valor de 64 bits. Sin embargo, esto es un problema, ya que los campos de posici\u00f3n y longitud del archivo de FS.FetchData son valores *firmados* de 32 bits. Solucione este problema capturando los bits de capacidad obtenidos del servidor de archivos cuando se env\u00eda un RPC FS.GetCapabilities, en lugar de simplemente descartarlos, y luego seleccionando el indicador VICED_CAPABILITY_64BITFILES. Esto luego se puede usar para decidir si usar FS.FetchData o FS.FetchData64, y tambi\u00e9n FS.StoreData o FS.StoreData64, en lugar de usar Upper_32_bits() para activar los valores de los par\u00e1metros. Este indicador de capacidades tambi\u00e9n podr\u00eda usarse para limitar el tama\u00f1o m\u00e1ximo del archivo, pero se deben verificar todos los servidores para eso. Tenga en cuenta que el problema no existe con FS.StoreData, que utiliza valores de 32 bits *sin firmar*. Tampoco es un problema con los servidores Auristor ya que su operaci\u00f3n YFS.FetchData64 utiliza valores de 64 bits sin firmar. Esto se puede probar clonando un repositorio de git a trav\u00e9s de un cliente OpenAFS en un servidor OpenAFS y luego ejecutando el \\\"estado de git\\\" desde un cliente afs de Linux[1]. Siempre que el clon tenga un archivo de paquete que est\u00e9 en el rango 2G-4G, el estado de git mostrar\u00e1 errores como: error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack no coincide con el \u00edndice error: packfile .git/objects/ pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack no coincide con el \u00edndice. Esto se puede observar en el FileLog del servidor y aparece algo como lo siguiente: Dom 29 de agosto 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114 , Anfitri\u00f3n 192.168.11.201:7001, Id 1001 dom 29 de agosto 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 dom 29 de agosto 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 dom 29 de agosto 19:3 1:39 2021 FetchData_RXStyle: tama\u00f1o de archivo 2400758866 ... domingo 29 de agosto 19:31:40 2021 SRXAFS_FetchData devuelve 5 Tenga en cuenta la posici\u00f3n del archivo de 18446744071815340032. Esta es la posici\u00f3n del archivo solicitada con signo extendido.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"fs/afs/fs_probe.c\",\"fs/afs/fsclient.c\",\"fs/afs/internal.h\",\"fs/afs/protocol_afs.h\",\"fs/afs/protocol_yfs.h\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"b9b1f8d5930a813879278d0cbfc8c658d6a038dc\",\"lessThan\":\"e66fc460d6dcf85cf12288e133a081205aebcd97\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b9b1f8d5930a813879278d0cbfc8c658d6a038dc\",\"lessThan\":\"b537a3c21775075395af475dcc6ef212fcf29db8\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"fs/afs/fs_probe.c\",\"fs/afs/fsclient.c\",\"fs/afs/internal.h\",\"fs/afs/protocol_afs.h\",\"fs/afs/protocol_yfs.h\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"2.6.22\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"2.6.22\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.14.9\",\"lessThanOrEqual\":\"5.14.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H\",\"baseScore\":7.1,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.2},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2024-06-17T17:37:26.717348Z\",\"id\":\"CVE-2021-47366\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-787\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"2.6.22\",\"versionEndExcluding\":\"5.14.9\",\"matchCriteriaId\":\"11311A36-8941-4E02-96B7-4807B83A7D81\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.15:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"E46C74C6-B76B-4C94-A6A4-FD2FFF62D644\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.15:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"60134C3A-06E4-48C1-B04F-2903732A4E56\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-08-04T19:58:10+00:00",
      "cve": "CVE-2021-47366",
      "id": "CVE-2021-47366",
      "initial_release_date": "2021-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2021/cve-2021-47366.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-08-08T00:05:45Z",
      "cve": "CVE-2021-47366",
      "id": "CVE-2021-47366",
      "initial_release_date": "2024-05-24T03:35:56Z",
      "product_status:known_affected": "275",
      "product_status:known_not_affected": "217",
      "product_status:recommended": "452",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2021-47366",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2021-47366.json",
      "version": "50"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-04T05:32:08.615Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2021-47366\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-06-17T17:37:26.717348Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-06-17T17:37:27.786Z\"}}], \"cna\": {\"title\": \"afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\", \"metrics\": [{\"cvssV3_1\": {\"version\": \"3.1\", \"baseScore\": 7.1, \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:L - The bug is in the kAFS client fetch path, reached via local read/page-cache I/O on an afs-mounted file (read_iter \\u2192 afs_issue_read \\u2192 afs_fs_fetch_data), not via unsolicited remote packet processing.\\nAC:L - An attacker who can read a file at offsets in the 2G-4G range against a non-YFS OpenAFS server triggers the wrong FS.FetchData RPC reliably; no race or uncontrolled memory layout is required.\\nPR:L - Triggering requires only an unprivileged local user able to open/read files on an already-mounted AFS volume (anonymous or user RxRPC key); CAP_SYS_ADMIN is needed to mount, but not to exercise the vulnerable read path.\\nUI:N - No separate victim action is required; the attacker initiates the read themselves, and AFS being mounted is an environmental precondition rather than user interaction.\\nS:U - Impact stays within normal kernel/filesystem behavior for the client (and collateral OpenAFS volume availability); there is no VM escape, sandbox escape, or other security-authority boundary cross.\\nC:N - The sign-extended position falls past EOF so the server returns an error rather than file data, and there is no kernel memory disclosure or other information leak.\\nI:H - The vulnerability is documented as read-data corruption (wrong/untrustworthy file contents in the 2G-4G range, e.g. git packfile mismatches), so integrity of returned file data is fully lost for affected regions.\\nA:H - Affected reads fail with remote I/O errors, and reproducers show the bad FetchData RPCs can take the OpenAFS volume offline for salvage, denying access to the shared volume.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"b9b1f8d5930a813879278d0cbfc8c658d6a038dc\", \"lessThan\": \"e66fc460d6dcf85cf12288e133a081205aebcd97\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b9b1f8d5930a813879278d0cbfc8c658d6a038dc\", \"lessThan\": \"b537a3c21775075395af475dcc6ef212fcf29db8\", \"versionType\": \"git\"}], \"programFiles\": [\"fs/afs/fs_probe.c\", \"fs/afs/fsclient.c\", \"fs/afs/internal.h\", \"fs/afs/protocol_afs.h\", \"fs/afs/protocol_yfs.h\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"2.6.22\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"2.6.22\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"5.14.9\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.14.*\"}, {\"status\": \"unaffected\", \"version\": \"5.15\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"fs/afs/fs_probe.c\", \"fs/afs/fsclient.c\", \"fs/afs/internal.h\", \"fs/afs/protocol_afs.h\", \"fs/afs/protocol_yfs.h\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97\"}, {\"url\": \"https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\\n\\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\\nLinux\u0027s afs client switches between them when talking to a non-YFS server\\nif the read size, the file position or the sum of the two have the upper 32\\nbits set of the 64-bit value.\\n\\nThis is a problem, however, since the file position and length fields of\\nFS.FetchData are *signed* 32-bit values.\\n\\nFix this by capturing the capability bits obtained from the fileserver when\\nit\u0027s sent an FS.GetCapabilities RPC, rather than just discarding them, and\\nthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be\\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\\nswitch on the parameter values.\\n\\nThis capabilities flag could also be used to limit the maximum size of the\\nfile, but all servers must be checked for that.\\n\\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\\n32-bit values.  It\u0027s also not a problem with Auristor servers as its\\nYFS.FetchData64 op uses unsigned 64-bit values.\\n\\nThis can be tested by cloning a git repo through an OpenAFS client to an\\nOpenAFS server and then doing \\\"git status\\\" on it from a Linux afs\\nclient[1].  Provided the clone has a pack file that\u0027s in the 2G-4G range,\\nthe git status will show errors like:\\n\\n\\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\\n\\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\\n\\nThis can be observed in the server\u0027s FileLog with something like the\\nfollowing appearing:\\n\\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\\n...\\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\\n\\nNote the file position of 18446744071815340032.  This is the requested file\\nposition sign-extended.\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.14.9\", \"versionStartIncluding\": \"2.6.22\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15\", \"versionStartIncluding\": \"2.6.22\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T08:47:28.087Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2021-47366\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-05T08:47:28.087Z\", \"dateReserved\": \"2024-05-21T14:58:30.810Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-05-21T15:03:33.176Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.