{"release":{"tag":{"name":"4.19.90-2302.1.0","path":"/openeuler/kernel/tags/4.19.90-2302.1.0","tree_path":"/openeuler/kernel/tree/4.19.90-2302.1.0","message":"4.19.90-2302.1.0","commit":{"id":"ac59b83e5b01ef06262e927dc7207adf8553c823","short_id":"ac59b83","title":"ring-buffer: Fix race between reset page and reading page","title_markdown":"ring-buffer: Fix race between reset page and reading page","description":"\nstable inclusion\nfrom stable-v4.19.262\ncommit 7e642bd051706d1174fbeb6ec0da8a1fc2189264\ncategory: bugfix\nbugzilla: https://gitee.com/openeuler/kernel/issues/I6CE9I\nCVE: NA\n\nReference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e642bd051706d1174fbeb6ec0da8a1fc2189264\n\n--------------------------------\n\ncommit a0fcaaed0c46cf9399d3a2d6e0c87ddb3df0e044 upstream.\n\nThe ring buffer is broken up into sub buffers (currently of page size).\nEach sub buffer has a pointer to its \"tail\" (the last event written to the\nsub buffer). When a new event is requested, the tail is locally\nincremented to cover the size of the new event. This is done in a way that\nthere is no need for locking.\n\nIf the tail goes past the end of the sub buffer, the process of moving to\nthe next sub buffer takes place. After setting the current sub buffer to\nthe next one, the previous one that had the tail go passed the end of the\nsub buffer needs to be reset back to the original tail location (before\nthe new event was requested) and the rest of the sub buffer needs to be\n\"padded\".\n\nThe race happens when a reader takes control of the sub buffer. As readers\ndo a \"swap\" of sub buffers from the ring buffer to get exclusive access to\nthe sub buffer, it replaces the \"head\" sub buffer with an empty sub buffer\nthat goes back into the writable portion of the ring buffer. This swap can\nhappen as soon as the writer moves to the next sub buffer and before it\nupdates the last sub buffer with padding.\n\nBecause the sub buffer can be released to the reader while the writer is\nstill updating the padding, it is possible for the reader to see the event\nthat goes past the end of the sub buffer. This can cause obvious issues.\n\nTo fix this, add a few memory barriers so that the reader definitely sees\nthe updates to the sub buffer, and also waits until the writer has put\nback the \"tail\" of the sub buffer back to the last event that was written\non it.\n\nTo be paranoid, it will only spin for 1 second, otherwise it will\nwarn and shutdown the ring buffer code. 1 second should be enough as\nthe writer does have preemption disabled. If the writer doesn't move\nwithin 1 second (with preemption disabled) something is horribly\nwrong. No interrupt should last 1 second!\n\nLink: https://lore.kernel.org/all/20220830120854.7545-1-jiazi.li@transsion.com/\nLink: https://bugzilla.kernel.org/show_bug.cgi?id=216369\nLink: https://lkml.kernel.org/r/20220929104909.0650a36c@gandalf.local.home\n\nCc: Ingo Molnar \u003Cmingo@kernel.org\u003E\nCc: Andrew Morton \u003Cakpm@linux-foundation.org\u003E\nCc: stable@vger.kernel.org\nFixes: c7b0930857e22 (\"ring-buffer: prevent adding write in discarded area\")\nReported-by: Jiazi.Li \u003Cjiazi.li@transsion.com\u003E\nSigned-off-by: Steven Rostedt (Google) \u003Crostedt@goodmis.org\u003E\nSigned-off-by: Greg Kroah-Hartman \u003Cgregkh@linuxfoundation.org\u003E\nSigned-off-by: Zheng Yejian \u003Czhengyejian1@huawei.com\u003E\nReviewed-by: Yang Jihong \u003Cyangjihong1@huawei.com\u003E\nSigned-off-by: Yongqiang Liu \u003Cliuyongqiang13@huawei.com\u003E","description_markdown":"stable inclusion\nfrom stable-v4.19.262\ncommit 7e642bd051706d1174fbeb6ec0da8a1fc2189264\ncategory: bugfix\nbugzilla: \u003Ca title=\"Issue: 【openEuler 1.0-LTS】回合主线trace特性相关的bugfix补丁\" class=\"gfm gfm-issue\" href=\"/open_euler/dashboard?issue_id=I6CE9I\"\u003E#I6CE9I\u003C/a\u003ECVE: NA\nReference: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fcommit%2F%3Fid%3D7e642bd051706d1174fbeb6ec0da8a1fc2189264\"\u003Ehttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e642bd051706d1174fbeb6ec0da8a1fc2189264\u003C/a\u003E\n--------------------------------\ncommit a0fcaaed0c46cf9399d3a2d6e0c87ddb3df0e044 upstream.\nThe ring buffer is broken up into sub buffers (currently of page size).\nEach sub buffer has a pointer to its \"tail\" (the last event written to the\nsub buffer). When a new event is requested, the tail is locally\nincremented to cover the size of the new event. This is done in a way that\nthere is no need for locking.\nIf the tail goes past the end of the sub buffer, the process of moving to\nthe next sub buffer takes place. After setting the current sub buffer to\nthe next one, the previous one that had the tail go passed the end of the\nsub buffer needs to be reset back to the original tail location (before\nthe new event was requested) and the rest of the sub buffer needs to be\n\"padded\".\nThe race happens when a reader takes control of the sub buffer. As readers\ndo a \"swap\" of sub buffers from the ring buffer to get exclusive access to\nthe sub buffer, it replaces the \"head\" sub buffer with an empty sub buffer\nthat goes back into the writable portion of the ring buffer. This swap can\nhappen as soon as the writer moves to the next sub buffer and before it\nupdates the last sub buffer with padding.\nBecause the sub buffer can be released to the reader while the writer is\nstill updating the padding, it is possible for the reader to see the event\nthat goes past the end of the sub buffer. This can cause obvious issues.\nTo fix this, add a few memory barriers so that the reader definitely sees\nthe updates to the sub buffer, and also waits until the writer has put\nback the \"tail\" of the sub buffer back to the last event that was written\non it.\nTo be paranoid, it will only spin for 1 second, otherwise it will\nwarn and shutdown the ring buffer code. 1 second should be enough as\nthe writer does have preemption disabled. If the writer doesn't move\nwithin 1 second (with preemption disabled) something is horribly\nwrong. No interrupt should last 1 second!\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flore.kernel.org%2Fall%2F20220830120854.7545-1-jiazi.li%40transsion.com%2F\"\u003Ehttps://lore.kernel.org/all/20220830120854.7545-1-jiazi.li@transsion.com/\u003C/a\u003E\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D216369\"\u003Ehttps://bugzilla.kernel.org/show_bug.cgi?id=216369\u003C/a\u003E\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flkml.kernel.org%2Fr%2F20220929104909.0650a36c%40gandalf.local.home\"\u003Ehttps://lkml.kernel.org/r/20220929104909.0650a36c@gandalf.local.home\u003C/a\u003E\nCc: Ingo Molnar \u003Ca href=\"mailto:mingo@kernel.org\"\u003Emingo@kernel.org\u003C/a\u003E\nCc: Andrew Morton \u003Ca href=\"mailto:akpm@linux-foundation.org\"\u003Eakpm@linux-foundation.org\u003C/a\u003E\nCc: \u003Ca href=\"mailto:stable@vger.kernel.org\"\u003Estable@vger.kernel.org\u003C/a\u003E\nFixes: c7b0930857e22 (\"ring-buffer: prevent adding write in discarded area\")\nReported-by: Jiazi.Li \u003Ca href=\"mailto:jiazi.li@transsion.com\"\u003Ejiazi.li@transsion.com\u003C/a\u003E\nSigned-off-by: Steven Rostedt (Google) \u003Ca href=\"mailto:rostedt@goodmis.org\"\u003Erostedt@goodmis.org\u003C/a\u003E\nSigned-off-by: Greg Kroah-Hartman \u003Ca href=\"mailto:gregkh@linuxfoundation.org\"\u003Egregkh@linuxfoundation.org\u003C/a\u003E\nSigned-off-by: Zheng Yejian \u003Ca href=\"mailto:zhengyejian1@huawei.com\"\u003Ezhengyejian1@huawei.com\u003C/a\u003E\nReviewed-by: Yang Jihong \u003Ca href=\"mailto:yangjihong1@huawei.com\"\u003Eyangjihong1@huawei.com\u003C/a\u003E\nSigned-off-by: Yongqiang Liu \u003Ca href=\"mailto:liuyongqiang13@huawei.com\"\u003Eliuyongqiang13@huawei.com\u003C/a\u003E","message":"ring-buffer: Fix race between reset page and reading page\n\nstable inclusion\nfrom stable-v4.19.262\ncommit 7e642bd051706d1174fbeb6ec0da8a1fc2189264\ncategory: bugfix\nbugzilla: https://gitee.com/openeuler/kernel/issues/I6CE9I\nCVE: NA\n\nReference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e642bd051706d1174fbeb6ec0da8a1fc2189264\n\n--------------------------------\n\ncommit a0fcaaed0c46cf9399d3a2d6e0c87ddb3df0e044 upstream.\n\nThe ring buffer is broken up into sub buffers (currently of page size).\nEach sub buffer has a pointer to its \"tail\" (the last event written to the\nsub buffer). When a new event is requested, the tail is locally\nincremented to cover the size of the new event. This is done in a way that\nthere is no need for locking.\n\nIf the tail goes past the end of the sub buffer, the process of moving to\nthe next sub buffer takes place. After setting the current sub buffer to\nthe next one, the previous one that had the tail go passed the end of the\nsub buffer needs to be reset back to the original tail location (before\nthe new event was requested) and the rest of the sub buffer needs to be\n\"padded\".\n\nThe race happens when a reader takes control of the sub buffer. As readers\ndo a \"swap\" of sub buffers from the ring buffer to get exclusive access to\nthe sub buffer, it replaces the \"head\" sub buffer with an empty sub buffer\nthat goes back into the writable portion of the ring buffer. This swap can\nhappen as soon as the writer moves to the next sub buffer and before it\nupdates the last sub buffer with padding.\n\nBecause the sub buffer can be released to the reader while the writer is\nstill updating the padding, it is possible for the reader to see the event\nthat goes past the end of the sub buffer. This can cause obvious issues.\n\nTo fix this, add a few memory barriers so that the reader definitely sees\nthe updates to the sub buffer, and also waits until the writer has put\nback the \"tail\" of the sub buffer back to the last event that was written\non it.\n\nTo be paranoid, it will only spin for 1 second, otherwise it will\nwarn and shutdown the ring buffer code. 1 second should be enough as\nthe writer does have preemption disabled. If the writer doesn't move\nwithin 1 second (with preemption disabled) something is horribly\nwrong. No interrupt should last 1 second!\n\nLink: https://lore.kernel.org/all/20220830120854.7545-1-jiazi.li@transsion.com/\nLink: https://bugzilla.kernel.org/show_bug.cgi?id=216369\nLink: https://lkml.kernel.org/r/20220929104909.0650a36c@gandalf.local.home\n\nCc: Ingo Molnar \u003Cmingo@kernel.org\u003E\nCc: Andrew Morton \u003Cakpm@linux-foundation.org\u003E\nCc: stable@vger.kernel.org\nFixes: c7b0930857e22 (\"ring-buffer: prevent adding write in discarded area\")\nReported-by: Jiazi.Li \u003Cjiazi.li@transsion.com\u003E\nSigned-off-by: Steven Rostedt (Google) \u003Crostedt@goodmis.org\u003E\nSigned-off-by: Greg Kroah-Hartman \u003Cgregkh@linuxfoundation.org\u003E\nSigned-off-by: Zheng Yejian \u003Czhengyejian1@huawei.com\u003E\nReviewed-by: Yang Jihong \u003Cyangjihong1@huawei.com\u003E\nSigned-off-by: Yongqiang Liu \u003Cliuyongqiang13@huawei.com\u003E\n","message_markdown":"ring-buffer: Fix race between reset page and reading page\nstable inclusion\nfrom stable-v4.19.262\ncommit 7e642bd051706d1174fbeb6ec0da8a1fc2189264\ncategory: bugfix\nbugzilla: \u003Ca title=\"Issue: 【openEuler 1.0-LTS】回合主线trace特性相关的bugfix补丁\" class=\"gfm gfm-issue\" href=\"/open_euler/dashboard?issue_id=I6CE9I\"\u003E#I6CE9I\u003C/a\u003ECVE: NA\nReference: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fcommit%2F%3Fid%3D7e642bd051706d1174fbeb6ec0da8a1fc2189264\"\u003Ehttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e642bd051706d1174fbeb6ec0da8a1fc2189264\u003C/a\u003E\n--------------------------------\ncommit a0fcaaed0c46cf9399d3a2d6e0c87ddb3df0e044 upstream.\nThe ring buffer is broken up into sub buffers (currently of page size).\nEach sub buffer has a pointer to its \"tail\" (the last event written to the\nsub buffer). When a new event is requested, the tail is locally\nincremented to cover the size of the new event. This is done in a way that\nthere is no need for locking.\nIf the tail goes past the end of the sub buffer, the process of moving to\nthe next sub buffer takes place. After setting the current sub buffer to\nthe next one, the previous one that had the tail go passed the end of the\nsub buffer needs to be reset back to the original tail location (before\nthe new event was requested) and the rest of the sub buffer needs to be\n\"padded\".\nThe race happens when a reader takes control of the sub buffer. As readers\ndo a \"swap\" of sub buffers from the ring buffer to get exclusive access to\nthe sub buffer, it replaces the \"head\" sub buffer with an empty sub buffer\nthat goes back into the writable portion of the ring buffer. This swap can\nhappen as soon as the writer moves to the next sub buffer and before it\nupdates the last sub buffer with padding.\nBecause the sub buffer can be released to the reader while the writer is\nstill updating the padding, it is possible for the reader to see the event\nthat goes past the end of the sub buffer. This can cause obvious issues.\nTo fix this, add a few memory barriers so that the reader definitely sees\nthe updates to the sub buffer, and also waits until the writer has put\nback the \"tail\" of the sub buffer back to the last event that was written\non it.\nTo be paranoid, it will only spin for 1 second, otherwise it will\nwarn and shutdown the ring buffer code. 1 second should be enough as\nthe writer does have preemption disabled. If the writer doesn't move\nwithin 1 second (with preemption disabled) something is horribly\nwrong. No interrupt should last 1 second!\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flore.kernel.org%2Fall%2F20220830120854.7545-1-jiazi.li%40transsion.com%2F\"\u003Ehttps://lore.kernel.org/all/20220830120854.7545-1-jiazi.li@transsion.com/\u003C/a\u003E\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D216369\"\u003Ehttps://bugzilla.kernel.org/show_bug.cgi?id=216369\u003C/a\u003E\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flkml.kernel.org%2Fr%2F20220929104909.0650a36c%40gandalf.local.home\"\u003Ehttps://lkml.kernel.org/r/20220929104909.0650a36c@gandalf.local.home\u003C/a\u003E\nCc: Ingo Molnar \u003Ca href=\"mailto:mingo@kernel.org\"\u003Emingo@kernel.org\u003C/a\u003E\nCc: Andrew Morton \u003Ca href=\"mailto:akpm@linux-foundation.org\"\u003Eakpm@linux-foundation.org\u003C/a\u003E\nCc: \u003Ca href=\"mailto:stable@vger.kernel.org\"\u003Estable@vger.kernel.org\u003C/a\u003E\nFixes: c7b0930857e22 (\"ring-buffer: prevent adding write in discarded area\")\nReported-by: Jiazi.Li \u003Ca href=\"mailto:jiazi.li@transsion.com\"\u003Ejiazi.li@transsion.com\u003C/a\u003E\nSigned-off-by: Steven Rostedt (Google) \u003Ca href=\"mailto:rostedt@goodmis.org\"\u003Erostedt@goodmis.org\u003C/a\u003E\nSigned-off-by: Greg Kroah-Hartman \u003Ca href=\"mailto:gregkh@linuxfoundation.org\"\u003Egregkh@linuxfoundation.org\u003C/a\u003E\nSigned-off-by: Zheng Yejian \u003Ca href=\"mailto:zhengyejian1@huawei.com\"\u003Ezhengyejian1@huawei.com\u003C/a\u003E\nReviewed-by: Yang Jihong \u003Ca href=\"mailto:yangjihong1@huawei.com\"\u003Eyangjihong1@huawei.com\u003C/a\u003E\nSigned-off-by: Yongqiang Liu \u003Ca href=\"mailto:liuyongqiang13@huawei.com\"\u003Eliuyongqiang13@huawei.com\u003C/a\u003E","detail_path":"/openeuler/kernel/commit/ac59b83e5b01ef06262e927dc7207adf8553c823","commits_path":"/openeuler/kernel/commits/ac59b83e5b01ef06262e927dc7207adf8553c823","tree_path":"/openeuler/kernel/tree/ac59b83e5b01ef06262e927dc7207adf8553c823","author":{"name":"Steven Rostedt (Google)","email":"rostedt@goodmis.org","username":null,"user_path":null,"enterprise_user_path":null,"image_path":"no_portrait.png#Steven Rostedt (Google)-","is_gitee_user":false,"is_enterprise_user":null,"widget_url":null},"committer":{"name":"Yongqiang Liu","email":"duanzi@zju.edu.cn","username":null,"user_path":null,"enterprise_user_path":null,"image_path":"no_portrait.png#Yongqiang Liu-","is_gitee_user":false,"is_enterprise_user":null,"widget_url":null},"authored_date":"2023-02-07T03:00:13+00:00","committed_date":"2023-02-07T11:02:58+08:00","signature":null,"build_state":null},"archive_path":"/openeuler/kernel/repository/archive/4.19.90-2302.1.0","signature":null},"operating":{"edit":false,"download":true,"destroy":false,"enterprise_forbid_zip":false},"release":{"title":"openEuler 20.03 update 4.19.90-2302.1.0","path":"/openeuler/kernel/releases/tag/4.19.90-2302.1.0","tag_path":"/openeuler/kernel/tree/4.19.90-2302.1.0","project_id":7696525,"created_at":"2023-02-07T21:00:02+08:00","is_prerelease":false,"description":"# 1TASK\r\n-------\r\n\r\n# 4.19.90-2301.6.0~1...4.19.90-2302.1.0\r\n-------\r\n| TASK | COMMIT |\r\n|:----:|:------:|\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I6CE9I | ac59b83e5b01 ring-buffer: Fix race between reset page and reading page\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I6B4N7 | 920e093b4b9a block: don't allow a disk link holder to itself\u003Cbr\u003E |\r\n|     bugzilla: 187904,https://gitee.com/openeuler/kernel/issues/I6BJAR | 7f6d120a3b83 ext4: fix use-after-free in ext4_orphan_cleanup\u003Cbr\u003Eeed57abe5e59 ext4: lost matching-pair of trace in ext4_truncate\u003Cbr\u003E |\r\n|     bugzilla: 188291, https://gitee.com/src-openeuler/kernel/issues/I6B1V2 | 34d18a87e565 ipv6: raw: Deduct extension header length in rawv6_push_pending_frames\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I6AWEO | a0fd3ba4fdbd mm/swapfile: add cond_resched() in get_swap_pages()\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I6AR36 | e9b25ed0117e hugetlbfs: don't delete error page from pagecache\u003Cbr\u003E e759fdf58083 mm: hwpoison: refactor refcount check handling\u003Cbr\u003E |\r\n|     bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I6BDME | db1c58801858 dhugetlb: set DYNAMIC_HUGETLB to y for hulk_defconfig\u003Cbr\u003E20bd30cdeb29 dhugetlb: use enable_dhugetlb to disable huge_memory\u003Cbr\u003E20f0535e57da dhugetlb: skip dissolve hugepage belonging to dynamic hugetlb\u003Cbr\u003Ef15774c66bcd dhugetlb: only support 1G/2M hugepage and ARM64_4K_PAGES\u003Cbr\u003E1cca8ee58207 dhugetlb: isolate dynamic hugetlb code\u003Cbr\u003E0bc0d0d57eda dhugetlb: backport dynamic hugetlb feature\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I69PY0 | b8042a6b91ce mm: fix false-positive OVERCOMMIT_GUESS failures\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6CGZN | ecf818a5ca64 cfq: fix memory leak for cfqq\u003Cbr\u003E |\r\n\r\n# 2CVE\r\n-------\r\n\r\n| CVE | issue |\r\n|:---:|:-----:|\r\n| CVE-2023-0394 | #I6B1V2 |\r\n\r\n","author":{"name":"Qiuuuuu","username":"qiuuuuu","path":"/qiuuuuu","avatar_url":"no_portrait.png#Qiuuuuu-qiuuuuu"},"attach_files":[],"zip_download_url":"/openeuler/kernel/releases/tag/4.19.90-2302.1.0.zip","tar_download_url":"/openeuler/kernel/releases/tag/4.19.90-2302.1.0.tar.gz"}}}