代码拉取完成，页面将自动刷新
一、漏洞信息
漏洞编号：CVE-2021-47366
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
CVSS V2.0分值：
BaseScore：0.0 None
Vector：CVSS：2.0/
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS serverAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, andLinux s afs client switches between them when talking to a non-YFS serverif the read size, the file position or the sum of the two have the upper 32bits set of the 64-bit value.This is a problem, however, since the file position and length fields ofFS.FetchData are signed 32-bit values.Fix this by capturing the capability bits obtained from the fileserver whenit s sent an FS.GetCapabilities RPC, rather than just discarding them, andthen picking out the VICED_CAPABILITY_64BITFILES flag. This can then beused to decide whether to use FS.FetchData or FS.FetchData64 - and alsoFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() toswitch on the parameter values.This capabilities flag could also be used to limit the maximum size of thefile, but all servers must be checked for that.Note that the issue does not exist with FS.StoreData - that uses unsigned32-bit values. It s also not a problem with Auristor servers as itsYFS.FetchData64 op uses unsigned 64-bit values.This can be tested by cloning a git repo through an OpenAFS client to anOpenAFS server and then doing git status on it from a Linux afsclient[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 indexThis can be observed in the server s FileLog with something like thefollowing appearing:Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866...Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5Note the file position of 18446744071815340032. This is the requested fileposition sign-extended.
漏洞公开时间：2024-05-21 23:15:22
漏洞创建时间：2024-05-22 02:51:16
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2021-47366
漏洞分析指导链接：
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息：
| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源 |
|---|---|---|---|---|
| linux | https://git.kernel.org/linus/b537a3c21775075395af475dcc6ef212fcf29db8 | https://git.kernel.org/linus/b9b1f8d5930a813879278d0cbfc8c658d6a038dc | ubuntu |
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS serverAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, andLinux s afs client switches between them when talking to a non-YFS serverif the read size, the file position or the sum of the two have the upper 32bits set of the 64-bit value.This is a problem, however, since the file position and length fields ofFS.FetchData are signed 32-bit values.Fix this by capturing the capability bits obtained from the fileserver whenit s sent an FS.GetCapabilities RPC, rather than just discarding them, andthen picking out the VICED_CAPABILITY_64BITFILES flag. This can then beused to decide whether to use FS.FetchData or FS.FetchData64 - and alsoFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() toswitch on the parameter values.This capabilities flag could also be used to limit the maximum size of thefile, but all servers must be checked for that.Note that the issue does not exist with FS.StoreData - that uses unsigned32-bit values. It s also not a problem with Auristor servers as itsYFS.FetchData64 op uses unsigned 64-bit values.This can be tested by cloning a git repo through an OpenAFS client to anOpenAFS server and then doing git status on it from a Linux afsclient[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 indexerror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match indexThis can be observed in the server s FileLog with something like thefollowing appearing:Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866...Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5Note the file position of 18446744071815340032. This is the requested fileposition sign-extended.
openEuler评分：
6.5
Vector：CVSS：3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
受影响版本排查(受影响/不受影响)：
1.openEuler-22.03-LTS-SP1(5.10.0):受影响
2.openEuler-22.03-LTS-SP3(5.10.0):受影响
3.openEuler-20.03-LTS-SP4(4.19.90):不受影响
4.openEuler-22.03-LTS-SP4(5.10.0):不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS(6.6.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响
修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP1(5.10.0):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.master(6.1.0):否
5.openEuler-24.03-LTS(6.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-22.03-LTS-SP4(5.10.0):否
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
| 参考网址 | 关联pr | 状态 | 补丁链接 |
|---|---|---|---|
| https://nvd.nist.gov/vuln/detail/CVE-2021-47366 | None | None | https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8 https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97 |
| https://ubuntu.com/security/CVE-2021-47366 | None | None | https://discourse.ubuntu.com/c/ubuntu-pro |
| https://www.opencve.io/cve/CVE-2021-47366 | None | None | https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8 https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97 |
| https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2021-47366 | |||
| https://security-tracker.debian.org/tracker/CVE-2021-47366 | None | None | https://git.kernel.org/linus/b537a3c21775075395af475dcc6ef212fcf29db8 |
说明：补丁链接仅供初步排查参考，实际可用性请人工再次确认，补丁下载验证可使用CVE补丁工具。
若补丁不准确，烦请在此issue下评论 '/report-patch 参考网址 补丁链接1,补丁链接2' 反馈正确信息，便于我们不断优化工具，不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1
hulk-robot
10个月前
CVE-2021-47366
影响性分析说明：
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.
openEuler评分:(评分和向量)
6.5
CVSS: 3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N
受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP1:受影响
2.openEuler-20.03-LTS-SP4:受影响
3.openEuler-22.03-LTS:不受影响
4.openEuler-22.03-LTS-SP1:受影响
5.openEuler-22.03-LTS-SP2:不受影响
6.openEuler-22.03-LTS-SP3:受影响
7.openEuler-22.03-LTS-SP4:不受影响
8.master(6.1.0):不受影响
9.openEuler-22.03-LTS-Next:不受影响
10.openEuler-24.03-LTS:不受影响
11.openEuler-24.03-LTS-Next:不受影响
修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP1(4.19.90):否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS:否
4.openEuler-22.03-LTS-SP1:否
5.openEuler-22.03-LTS-SP2:否
6.openEuler-22.03-LTS-SP3:否
7.master(6.1.0):否
8.openEuler-22.03-LTS-Next:否
9.openEuler-24.03-LTS:否
10.openEuler-24.03-LTS-Next:否
11.openEuler-22.03-LTS-SP4:否
hulk-robot
10个月前
CVE-2021-47366
影响性分析说明：
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.
openEuler评分:(评分和向量)
6.5
CVSS: 3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N
受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP1:受影响
2.openEuler-20.03-LTS-SP4:受影响
3.openEuler-22.03-LTS:不受影响
4.openEuler-22.03-LTS-SP1:受影响
5.openEuler-22.03-LTS-SP2:不受影响
6.openEuler-22.03-LTS-SP3:受影响
7.openEuler-22.03-LTS-SP4:不受影响
8.master(6.1.0):不受影响
9.openEuler-22.03-LTS-Next:不受影响
10.openEuler-24.03-LTS:不受影响
11.openEuler-24.03-LTS-Next:不受影响
修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP1(4.19.90):否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS:否
4.openEuler-22.03-LTS-SP1:否
5.openEuler-22.03-LTS-SP2:否
6.openEuler-22.03-LTS-SP3:否
7.master(6.1.0):否
8.openEuler-22.03-LTS-Next:否
9.openEuler-24.03-LTS:否
10.openEuler-24.03-LTS-Next:否
11.openEuler-22.03-LTS-SP4:否
CVE-2021-47366
影响性分析说明：
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.
openEuler评分:(评分和向量)
6.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:不受影响
7.openEuler-24.03-LTS-Next:不受影响
修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否
===========================================================
登录 后才可以发表评论
FileDragTip