{"release":{"tag":{"name":"4.19.90-2107.5.0","path":"/openeuler/kernel/tags/4.19.90-2107.5.0","tree_path":"/openeuler/kernel/tree/4.19.90-2107.5.0","message":"4.19.90-2107.5.0","commit":{"id":"264a9db9224416c198ed4ceff9d37f200258bf8e","short_id":"264a9db","title":"mm: vmalloc: prevent use after free in _vm_unmap_aliases","title_markdown":"mm: vmalloc: prevent use after free in _vm_unmap_aliases","description":"\nmainline inclusion\nfrom mainline-5.13-rc1\ncommit ad216c0316ad6391d90f4de0a7f59396b2925a06\ncategory: bugfix\nbugzilla: 56231\nCVE: NA\n\n-------------------------------------------------\nA potential use after free can occur in _vm_unmap_aliases where an already\nfreed vmap_area could be accessed, Consider the following scenario:\n\nProcess 1\t\t\t\t\t\tProcess 2\n\n__vm_unmap_aliases\t\t\t\t\t__vm_unmap_aliases\n\tpurge_fragmented_blocks_allcpus\t\t\t\trcu_read_lock()\n\t\trcu_read_lock()\n\t\t\tlist_del_rcu(\u0026vb-\u003Efree_list)\n\t\t\t\t\t\t\t\t\tlist_for_each_entry_rcu(vb .. )\n\t__purge_vmap_area_lazy\n\t\tkmem_cache_free(va)\n\t\t\t\t\t\t\t\t\t\tva_start = vb-\u003Eva-\u003Eva_start\n\nHere Process 1 is in purge path and it does list_del_rcu on vmap_block and\nlater frees the vmap_area, since Process 2 was holding the rcu lock at\nthis time vmap_block will still be present in and Process 2 accesse it and\nthereby it tries to access vmap_area of that vmap_block which was already\nfreed by Process 1 and this results in use after free.\n\nFix this by adding a check for vb-\u003Edirty before accessing vmap_area\nstructure since vb-\u003Edirty will be set to VMAP_BBMAP_BITS in purge path\nchecking for this will prevent the use after free.\n\nLink: https://lkml.kernel.org/r/1616062105-23263-1-git-send-email-vjitta@codeaurora.org\nSigned-off-by: Vijayanand Jitta \u003Cvjitta@codeaurora.org\u003E\nReviewed-by: Uladzislau Rezki (Sony) \u003Curezki@gmail.com\u003E\nSigned-off-by: Andrew Morton \u003Cakpm@linux-foundation.org\u003E\nSigned-off-by: Linus Torvalds \u003Ctorvalds@linux-foundation.org\u003E\n(cherry picked from commit ad216c0316ad6391d90f4de0a7f59396b2925a06)\nSigned-off-by: Yue Zou \u003Czouyue3@huawei.com\u003E\nReviewed-by: Kefeng Wang \u003Cwangkefeng.wang@huawei.com\u003E\nReviewed-by: tong tiangen \u003Ctongtiangen@huawei.com\u003E\nSigned-off-by: Yang Yingliang \u003Cyangyingliang@huawei.com\u003E","description_markdown":"mainline inclusion\nfrom mainline-5.13-rc1\ncommit ad216c0316ad6391d90f4de0a7f59396b2925a06\ncategory: bugfix\nbugzilla: 56231\nCVE: NA\n-------------------------------------------------\nA potential use after free can occur in _vm_unmap_aliases where an already\nfreed vmap_area could be accessed, Consider the following scenario:\nProcess 1                       Process 2\n__vm_unmap_aliases                  __vm_unmap_aliases\npurge_fragmented_blocks_allcpus             rcu_read_lock()\nrcu_read_lock()\nlist_del_rcu(\u0026amp;vb-\u0026gt;free_list)\nlist_for_each_entry_rcu(vb .. )\n__purge_vmap_area_lazy\nkmem_cache_free(va)\nva_start = vb-\u0026gt;va-\u0026gt;va_start\nHere Process 1 is in purge path and it does list_del_rcu on vmap_block and\nlater frees the vmap_area, since Process 2 was holding the rcu lock at\nthis time vmap_block will still be present in and Process 2 accesse it and\nthereby it tries to access vmap_area of that vmap_block which was already\nfreed by Process 1 and this results in use after free.\nFix this by adding a check for vb-\u0026gt;dirty before accessing vmap_area\nstructure since vb-\u0026gt;dirty will be set to VMAP_BBMAP_BITS in purge path\nchecking for this will prevent the use after free.\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flkml.kernel.org%2Fr%2F1616062105-23263-1-git-send-email-vjitta%40codeaurora.org\"\u003Ehttps://lkml.kernel.org/r/1616062105-23263-1-git-send-email-vjitta@codeaurora.org\u003C/a\u003E\nSigned-off-by: Vijayanand Jitta \u003Ca href=\"mailto:vjitta@codeaurora.org\"\u003Evjitta@codeaurora.org\u003C/a\u003E\nReviewed-by: Uladzislau Rezki (Sony) \u003Ca href=\"mailto:urezki@gmail.com\"\u003Eurezki@gmail.com\u003C/a\u003E\nSigned-off-by: Andrew Morton \u003Ca href=\"mailto:akpm@linux-foundation.org\"\u003Eakpm@linux-foundation.org\u003C/a\u003E\nSigned-off-by: Linus Torvalds \u003Ca href=\"mailto:torvalds@linux-foundation.org\"\u003Etorvalds@linux-foundation.org\u003C/a\u003E\n(cherry picked from commit ad216c0316ad6391d90f4de0a7f59396b2925a06)\nSigned-off-by: Yue Zou \u003Ca href=\"mailto:zouyue3@huawei.com\"\u003Ezouyue3@huawei.com\u003C/a\u003E\nReviewed-by: Kefeng Wang \u003Ca href=\"mailto:wangkefeng.wang@huawei.com\"\u003Ewangkefeng.wang@huawei.com\u003C/a\u003E\nReviewed-by: tong tiangen \u003Ca href=\"mailto:tongtiangen@huawei.com\"\u003Etongtiangen@huawei.com\u003C/a\u003E\nSigned-off-by: Yang Yingliang \u003Ca href=\"mailto:yangyingliang@huawei.com\"\u003Eyangyingliang@huawei.com\u003C/a\u003E","message":"mm: vmalloc: prevent use after free in _vm_unmap_aliases\n\nmainline inclusion\nfrom mainline-5.13-rc1\ncommit ad216c0316ad6391d90f4de0a7f59396b2925a06\ncategory: bugfix\nbugzilla: 56231\nCVE: NA\n\n-------------------------------------------------\nA potential use after free can occur in _vm_unmap_aliases where an already\nfreed vmap_area could be accessed, Consider the following scenario:\n\nProcess 1\t\t\t\t\t\tProcess 2\n\n__vm_unmap_aliases\t\t\t\t\t__vm_unmap_aliases\n\tpurge_fragmented_blocks_allcpus\t\t\t\trcu_read_lock()\n\t\trcu_read_lock()\n\t\t\tlist_del_rcu(\u0026vb-\u003Efree_list)\n\t\t\t\t\t\t\t\t\tlist_for_each_entry_rcu(vb .. )\n\t__purge_vmap_area_lazy\n\t\tkmem_cache_free(va)\n\t\t\t\t\t\t\t\t\t\tva_start = vb-\u003Eva-\u003Eva_start\n\nHere Process 1 is in purge path and it does list_del_rcu on vmap_block and\nlater frees the vmap_area, since Process 2 was holding the rcu lock at\nthis time vmap_block will still be present in and Process 2 accesse it and\nthereby it tries to access vmap_area of that vmap_block which was already\nfreed by Process 1 and this results in use after free.\n\nFix this by adding a check for vb-\u003Edirty before accessing vmap_area\nstructure since vb-\u003Edirty will be set to VMAP_BBMAP_BITS in purge path\nchecking for this will prevent the use after free.\n\nLink: https://lkml.kernel.org/r/1616062105-23263-1-git-send-email-vjitta@codeaurora.org\nSigned-off-by: Vijayanand Jitta \u003Cvjitta@codeaurora.org\u003E\nReviewed-by: Uladzislau Rezki (Sony) \u003Curezki@gmail.com\u003E\nSigned-off-by: Andrew Morton \u003Cakpm@linux-foundation.org\u003E\nSigned-off-by: Linus Torvalds \u003Ctorvalds@linux-foundation.org\u003E\n(cherry picked from commit ad216c0316ad6391d90f4de0a7f59396b2925a06)\nSigned-off-by: Yue Zou \u003Czouyue3@huawei.com\u003E\nReviewed-by: Kefeng Wang \u003Cwangkefeng.wang@huawei.com\u003E\nReviewed-by: tong tiangen \u003Ctongtiangen@huawei.com\u003E\nSigned-off-by: Yang Yingliang \u003Cyangyingliang@huawei.com\u003E\n","message_markdown":"mm: vmalloc: prevent use after free in _vm_unmap_aliases\nmainline inclusion\nfrom mainline-5.13-rc1\ncommit ad216c0316ad6391d90f4de0a7f59396b2925a06\ncategory: bugfix\nbugzilla: 56231\nCVE: NA\n-------------------------------------------------\nA potential use after free can occur in _vm_unmap_aliases where an already\nfreed vmap_area could be accessed, Consider the following scenario:\nProcess 1                       Process 2\n__vm_unmap_aliases                  __vm_unmap_aliases\npurge_fragmented_blocks_allcpus             rcu_read_lock()\nrcu_read_lock()\nlist_del_rcu(\u0026amp;vb-\u0026gt;free_list)\nlist_for_each_entry_rcu(vb .. )\n__purge_vmap_area_lazy\nkmem_cache_free(va)\nva_start = vb-\u0026gt;va-\u0026gt;va_start\nHere Process 1 is in purge path and it does list_del_rcu on vmap_block and\nlater frees the vmap_area, since Process 2 was holding the rcu lock at\nthis time vmap_block will still be present in and Process 2 accesse it and\nthereby it tries to access vmap_area of that vmap_block which was already\nfreed by Process 1 and this results in use after free.\nFix this by adding a check for vb-\u0026gt;dirty before accessing vmap_area\nstructure since vb-\u0026gt;dirty will be set to VMAP_BBMAP_BITS in purge path\nchecking for this will prevent the use after free.\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flkml.kernel.org%2Fr%2F1616062105-23263-1-git-send-email-vjitta%40codeaurora.org\"\u003Ehttps://lkml.kernel.org/r/1616062105-23263-1-git-send-email-vjitta@codeaurora.org\u003C/a\u003E\nSigned-off-by: Vijayanand Jitta \u003Ca href=\"mailto:vjitta@codeaurora.org\"\u003Evjitta@codeaurora.org\u003C/a\u003E\nReviewed-by: Uladzislau Rezki (Sony) \u003Ca href=\"mailto:urezki@gmail.com\"\u003Eurezki@gmail.com\u003C/a\u003E\nSigned-off-by: Andrew Morton \u003Ca href=\"mailto:akpm@linux-foundation.org\"\u003Eakpm@linux-foundation.org\u003C/a\u003E\nSigned-off-by: Linus Torvalds \u003Ca href=\"mailto:torvalds@linux-foundation.org\"\u003Etorvalds@linux-foundation.org\u003C/a\u003E\n(cherry picked from commit ad216c0316ad6391d90f4de0a7f59396b2925a06)\nSigned-off-by: Yue Zou \u003Ca href=\"mailto:zouyue3@huawei.com\"\u003Ezouyue3@huawei.com\u003C/a\u003E\nReviewed-by: Kefeng Wang \u003Ca href=\"mailto:wangkefeng.wang@huawei.com\"\u003Ewangkefeng.wang@huawei.com\u003C/a\u003E\nReviewed-by: tong tiangen \u003Ca href=\"mailto:tongtiangen@huawei.com\"\u003Etongtiangen@huawei.com\u003C/a\u003E\nSigned-off-by: Yang Yingliang \u003Ca href=\"mailto:yangyingliang@huawei.com\"\u003Eyangyingliang@huawei.com\u003C/a\u003E","detail_path":"/openeuler/kernel/commit/264a9db9224416c198ed4ceff9d37f200258bf8e","commits_path":"/openeuler/kernel/commits/264a9db9224416c198ed4ceff9d37f200258bf8e","tree_path":"/openeuler/kernel/tree/264a9db9224416c198ed4ceff9d37f200258bf8e","author":{"name":"Vijayanand Jitta","email":"vjitta@codeaurora.org","username":null,"user_path":null,"enterprise_user_path":null,"image_path":"no_portrait.png#Vijayanand Jitta-","is_gitee_user":false,"is_enterprise_user":null,"widget_url":null},"committer":{"name":"YangYingliang","email":"yangyingliang@huawei.com","username":"yangyingliang","user_path":"/yangyingliang","enterprise_user_path":"/open_euler/dashboard/members/yangyingliang","image_path":"no_portrait.png#YangYingliang-yangyingliang","is_gitee_user":true,"is_enterprise_user":true,"widget_url":""},"authored_date":"2021-07-23T15:54:57+08:00","committed_date":"2021-07-23T16:01:45+08:00","signature":null,"build_state":null},"archive_path":"/openeuler/kernel/repository/archive/4.19.90-2107.5.0","signature":null},"operating":{"edit":false,"download":true,"destroy":false,"enterprise_forbid_zip":false},"release":{"title":"openEuler 20.03 update 4.19.90-2107.5.0","path":"/openeuler/kernel/releases/tag/4.19.90-2107.5.0","tag_path":"/openeuler/kernel/tree/4.19.90-2107.5.0","project_id":7696525,"created_at":"2021-07-27T20:18:11+08:00","is_prerelease":false,"description":"# bugfix/feature\r\n-------\r\n\r\n| TASK | COMMIT |\r\n|:----:|:------:|\r\n|     bugzilla: 56231 | 264a9db92244 mm: vmalloc: prevent use after free in _vm_unmap_aliases\u003Cbr\u003E |\r\n|     bugzilla: NA | 2ec3b1c41b1b PCI/sysfs: Take reference on device to be removed\u003Cbr\u003E |\r\n|     bugzilla: NA | 78f93fa99e08 ARM: footbridge: remove personal server platform\u003Cbr\u003E |\r\n|     bugzilla: 174641 | d0ffe36fdd12 mm: slab: fix kmem_cache_create failed when sysfs node not destroyed\u003Cbr\u003E |\r\n|     bugzilla: 167363 | aff88a42f3e2 nvme-pci: use atomic bitops to mark a queue enabled\u003Cbr\u003Ec22fd840d2ba nvme: check the PRINFO bit before deciding the host buffer length\u003Cbr\u003Eb8ba22a604e4 nvme: fix compat address handling in several ioctls\u003Cbr\u003E9a29c022b11f nvme-core: make implicit seed truncation explicit\u003Cbr\u003Eda29c9dd7c6e nvme-core: don't use NVME_NSID_ALL for command effects and supported log\u003Cbr\u003E902a53aa3026 nvme-pci: fix NULL req in completion handler\u003Cbr\u003E47f62e004041 nvme-pci: cancel nvme device request before disabling\u003Cbr\u003Eb946d8f99a86 nvme: copy MTFA field from identify controller\u003Cbr\u003Eed4538b7efcc nvme-pci: Unblock reset_work on IO failure\u003Cbr\u003E458f847098f2 nvme-pci: Don't disable on timeout in reset state\u003Cbr\u003E85613d464e6a nvme-pci: Fix controller freeze wait disabling\u003Cbr\u003E |\r\n|     bugzilla: 174635 | d4a6a4473625 block: error out if blk_get_queue() failed in blk_init_rl()\u003Cbr\u003E |\r\n\r\n\r\n# CVE\r\n-------\r\n\r\n| CVE | issue |\r\n|:---:|:-----:|\r\n| CVE-2021-32078 | #I3XAHM |\r\n| CVE-2021-33909 | #I42461 |\r\n\r\n#I3XAHM #I42461\r\n\r\n","author":{"name":"成坚  (CHENG Jian)","username":"gatieme","path":"/gatieme","avatar_url":"no_portrait.png#成坚  (CHENG Jian)-gatieme"},"attach_files":[],"zip_download_url":"/openeuler/kernel/releases/tag/4.19.90-2107.5.0.zip","tar_download_url":"/openeuler/kernel/releases/tag/4.19.90-2107.5.0.tar.gz"}}}