Improper Input Validation Affecting kernel package, versions <0:4.14.238-182.421.amzn2
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-AMZN2-KERNEL-7678678
- published 14 Aug 2024
- disclosed 15 Mar 2024
Introduced: 15 Mar 2024
CVE-2021-47117 Open this link in a new tabHow to fix?
Upgrade Amazon-Linux:2 kernel to version 0:4.14.238-182.421.amzn2 or higher.
This issue was patched in ALAS2-2021-1685.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel package and not the kernel package as distributed by Amazon-Linux.
See How to fix? for Amazon-Linux:2 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed
We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330 [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110] ksys_read+0x74/0xf0
This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)."
References
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-47117
- https://git.kernel.org/stable/c/082cd4ec240b8734a82a89ffb890216ac98fec68
- https://git.kernel.org/stable/c/48105dc98c9ca35af418746277b087cb2bc6df7c
- https://git.kernel.org/stable/c/569496aa3776eea1ff0d49d0174ac1b7e861e107
- https://git.kernel.org/stable/c/5b3a9a2be59478b013a430ac57b0f3d65471b071
- https://git.kernel.org/stable/c/920697b004e49cb026e2e15fe91be065bf0741b7
- https://git.kernel.org/stable/c/d3b668b96ad3192c0581a248ae2f596cd054792a
- https://git.kernel.org/stable/c/d8116743ef5432336289256b2f7c117299213eb9
- https://git.kernel.org/stable/c/e33bafad30d34cfa5e9787cb099cab05e2677fcb