diff --git a/docs/linux/reporting_kernel_bugs.drawio b/docs/linux/reporting_kernel_bugs.drawio
new file mode 100644
index 000000000000..a056bdbd1464
--- /dev/null
+++ b/docs/linux/reporting_kernel_bugs.drawio
@@ -0,0 +1,287 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/linux/reporting_kernel_bugs.md b/docs/linux/reporting_kernel_bugs.md
index 78d182b05c16..202048c5b3ae 100644
--- a/docs/linux/reporting_kernel_bugs.md
+++ b/docs/linux/reporting_kernel_bugs.md
@@ -52,61 +52,119 @@ If you can't figure out the right fix, but have some understanding of the bug, p
## Reporting security bugs
-If you believe that a found bug poses potential security threat, consider following the instructions below.
-Note, that these instructions are a work-in-progress and based on my current understanding of the disclosure process.
-This instruction is now being discussed [here](http://seclists.org/oss-sec/2017/q3/242).
+If you believe that a found bug poses potential security threat, consider the following instructions below.
+Initial version was discussed [here](http://seclists.org/oss-sec/2017/q3/242).
-If you don't want to deal with this complex disclosure process you can either:
+The three main mailing lists for reporting and disclosing Linux kernel security issues are listed below with guidelines.
+Please read them carefully before sending anything to these lists.
-1. Report the bug privately to `security@kernel.org`. In this case it should be fixed in the upstream kernel, but there are no guarantees that the fix will be propagated to stable or distro kernels. The maximum embargo on this list is 7 days.
-2. Report the bug privately to a vendor such as Red Hat (`secalert@redhat.com`) or SUSE (`security@suse.com`). They should fix the bug, assign a CVE, and notify other vendors. The maximum embargo on these lists is 5 weeks.
-3. Report the bug publicly to `oss-security@lists.openwall.com`.
+1. `security@kernel.org` - https://docs.kernel.org/process/security-bugs.html.
-If you want to deal with the disclosure yourself, read below.
+ The security team wants to release the fix ASAP, but can be postponed if the reporter asks an embargo period to let linux-distros update their kernels.
-The three main mailing lists for reporting and disclosing Linux kernel security issues are `security@kernel.org`, `linux-distros@vs.openwall.org` and `oss-security@lists.openwall.com`.
-The links for the guidelines for these lists are below, please read them carefully before sending anything to these lists.
+2. `linux-distros@vs.openwall.org` - https://oss-security.openwall.org/wiki/mailing-lists/distros
-1. `security@kernel.org` - https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
-2. `linux-distros@vs.openwall.org` - http://oss-security.openwall.org/wiki/mailing-lists/distros
-3. `oss-security@lists.openwall.com` - http://oss-security.openwall.org/wiki/mailing-lists/oss-security
+ People want to roll out the ready, actionable, non-public fix to distributions within the embargoed period.
-### Reporting minor security bugs
+3. `oss-security@lists.openwall.com` - https://oss-security.openwall.org/wiki/mailing-lists/oss-security
-To report minor security bugs (such as local DOS or local info leak):
+ Public disclosure to the security group with the optional exploitation write-up, CVE mentioning.
-1. Report the bug publicly to kernel developers as described above and wait until a fix is committed. Alternatively, you can develop and send a fix yourself.
-2. Request a CVE from MITRE through [the web form](https://cveform.mitre.org/). Describe the bug details and add a link to the fix (from `patchwork.kernel.org`, `git.kernel.org` or `github.com`) in the request.
-3. Once a CVE is assigned, send the bug details, the CVE number and a link to the fix to `oss-security@lists.openwall.com`.
+4. `cve@kernel.org` - https://www.kernel.org/doc/html/latest/process/cve.html
-### Reporting major security bugs
+ Official kernel.org CNA. CVE assignment team has own procedure of manual voting whether the bug is CVE eligible.
-To report major security bugs (such as LPE, remote DOS, remote info leak or RCE):
+### Vulnerability definition
-1. Understand the bug and develop a patch with a fix if possible. Optionally develop a proof-of-concept exploit.
-2. Notify `security@kernel.org`:
- * Describe vulnerability details, include the proposed patch and optionally the exploit.
- * Ask for 7 days of embargo.
- * Work on the patch together with the `security@kernel.org` members.
-3. Notify `linux-distros@vs.openwall.org`:
- * Describe vulnerability details, include the proposed patch and optionally the exploit.
- * Ask them to assign a CVE number.
- * Ask for 7 days of embargo.
-4. Wait 7 days for linux distros to apply the patch.
-5. Ask `linux-distros@vs.openwall.org` to make the CVE description public and roll out the updated kernels.
-6. Send the fix upstream:
- * Mention the CVE number in the commit message.
- * Mention syzkaller in the commit message.
-7. Notify `oss-security@lists.openwall.com`:
- * Describe vulnerability details, include a link to the committed patch.
-8. Wait 1-3 days for people to update their kernels.
-9. Optionally publish the exploit on `oss-security@lists.openwall.com`.
+From [cve.org](https://www.cve.org/resourcessupport/allresources/cnarules):
+
+> A vulnerability is an instance of one or more weaknesses in a Product that can be exploited,
+> causing a negative impact to confidentiality, integrity, or availability; a set of conditions
+> or behaviors that allows the violation of an explicit or implicit security policy.
+
+Translating to the kernel vulnerability definition per [Greg Kroah-Hartman](https://youtu.be/KumwRn1BA6s?t=203):
+> * Any user-triggerable crash or reboot
+> * Memory UAF / leak / overflow (even 1 byte)
+> * Incorrect boundary checks
+> * Denial of service
+> * Logic errors & lots of other things*
+
+*Data corruption/loss, performance issues, bugfixes that are not externally triggered are NOT considered as the kernel vulnerability.
+
+### Normal Linux kernel security bug reporting
+
+"Normal" means the security bug reported to `security@kernel.org` according to the [kernel.org instructions](https://docs.kernel.org/process/security-bugs.html),
+**without** the CVE requirement.
+
+Report the bug privately to `security@kernel.org` which is interested only in getting bugs fixed.
+There are no guarantees that the fix will be propagated to stable or distro kernels.
+The maximum embargo on this list is **7 days from the moment** from the start of the released fix process,
+whereas for "linux-distros" the embargoed period starts from the initial post to the list
+regardless of the availability of a fix.
+
+That's why it's strongly recommended, do NOT include "[linux-distros](https://oss-security.openwall.org/wiki/mailing-lists/distros)" mailing lists in CC
+UNTIL the fix is accepted by affected systems' maintainers.
+> In other words, until a fix is accepted do not Cc: “linux-distros”, and after it’s merged do not Cc: the kernel security team.
+
+During reporting the security bug to `security@kernel.org`, keep everything in **plain text**, including the fix, exploit code etc.,
+think of it like a [regular Linux kernel patch submission](https://docs.kernel.org/process/submitting-patches.html).
+
+Note that `security@kernel.org` doesn't assign CVE as they simply do not require it. See CVE assignment instructions below.
-A few notes:
+### CVE assignment
-* There should ideally be no delay between reports to `security@kernel.org` and `linux-distros@vs.openwall.org`.
-* When working on the patch together with the `security@kernel.org` members and upstream maintainers, keep the linux-distros aware of the progress.
-* There should ideally be no delay between CVE description publication, distros' updates, upstream commit and notification to `oss-security@lists.openwall.com`. All of these should be on the same day, at worst.
-* The moment the issue is made public (e.g. patch is submitted upstream, CVE description published, etc.) it must be reported to `oss-security@lists.openwall.com` right away.
+kernel.org is now CNA (from [February 13, 2024](https://www.cve.org/Media/News/item/news/2024/02/13/kernel-org-Added-as-CNA)),
+therefore they have reserved CVE IDs for the kernel vulnerability bugs classified as CVE.
-A good example of an LPE announcement structure on `oss-security@lists.openwall.com` can be found [here](http://seclists.org/oss-sec/2016/q4/607), however the timeline doesn't look right there: public announcement should have occurred right after the patch was submitted to netdev.
+CVE assignments (sometimes rejections) are publicly announced in public list, see [linux-cve-announce](https://lore.kernel.org/linux-cve-announce) on which you can [subscribe](https://subspace.kernel.org/subscribing.html).
+
+CVEs are assigned after-the-fact with 1-2 week delay usually.
+> No hardware CVEs (SPECTRE-like CVEs come from others) (c) Greg K-H
+
+, e.g. bugs in drivers are Linux kernel related, hence they can be treated as CVEs, and HW bugs in CPU, NIC, other chips that affect Linux kernel, Windows, OSX etc.
+that are not caused due to Linux kernel code, should be handled by HW vendor.
+
+Averaging 55 CVEs per week (2024 Q3):
+> CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify
+> This explains the seemingly large number of CVEs that are issued by the Linux kernel team.
+
+Kernel CVE assignment process is explained [here](https://www.kernel.org/doc/html/latest/process/cve.html), quoting the important paragraph:
+> If the CVE assignment team misses a specific fix that any user feels should have a CVE assigned to it,
+> please email them at and the team there will work with you on it.
+> Note that no potential security issues should be sent to this alias,
+> it is ONLY for assignment of CVEs for fixes that are already in released kernel trees.
+> If you feel you have found an unfixed security issue, please follow the [normal Linux kernel security bug reporting process](https://docs.kernel.org/process/security-bugs.html).
+
+Note that kernel.org assigns CVE in a very descriptive format (which files, versions are effected etc.).
+See [CVE-2024-50078](https://lore.kernel.org/linux-cve-announce/2024102936-CVE-2024-50078-cfe9@gregkh/T/#u) as an example.
+
+### Process
+
+
+
+1. Understand the bug and develop a patch with a fix if possible. Optionally develop a proof-of-concept exploit.
+ * Notify `security@kernel.org`
+ * As the recommendation, do not include `linux-distros@vs.openwall.org` in conversation at this moment.
+ * Describe vulnerability details, include the proposed patch and optionally the exploit **in plain text**.
+ * Security team may include in the mailing list necessary maintainers for the confirmation if you haven't included them yet.
+ * Work on the patch (fix) together with the `security@kernel.org` and affected system maintainers.
+ * If the bug is found via syzbot report, make sure that the patch includes `Fixes` tag of the correspondent syzbot report.
+
+2. If the fix is merged to the kernel stable tree, hence it's publicly available:
+ * Notify `oss-security@lists.openwall.com`:
+ * Describe vulnerability details, include a link to the committed patch.
+ * See step 4. if CVE is required.
+ * If all distros have released the update with the fix, then optionally publish the exploit on `oss-security@lists.openwall.com`, and the link to write-up if there is any.
+3. If the fix is not merged yet:
+ * Notify `linux-distros@vs.openwall.org` in the same mailing list for convenience
+ * Describe vulnerability details, include the accepted earlier patch and optionally the exploit.
+ * If the fix can wait for the embargo period (up to 7 calendar days):
+ * Ask for 7 calendar days of embargo. Within this time, distro people can update their kernels and the fix can land in the stable tree.
+ * otherwise,
+ * the fix can be merged to the stable tree ASAP per `security@kernel.org`'s preference.
+4. Once the fix is merged to the stable tree and it's now offically, publicly available:
+ * If CVE is applicable to this bug (see [Vulnerability definition](#vulnerability-definition)), the proceed with CVE assigment:
+ * Check [linux-cve-announce](https://lore.kernel.org/linux-cve-announce) if the CVE is assigned to your security bug's fix
+ * If CVE is missing, then:
+ * request CVE from `cve@kernel.org` by pointing to the upstream fix
+ * Optionally, notify `oss-security@lists.openwall.com` as described in step 2.
diff --git a/docs/linux/reporting_kernel_bugs.png b/docs/linux/reporting_kernel_bugs.png
new file mode 100644
index 000000000000..731480377d96
Binary files /dev/null and b/docs/linux/reporting_kernel_bugs.png differ