I wanted to know how many CVEs were assigned to DAMON, and then I wanted to know the numbers for other subsystems as well. So I wrote a script: https://github.com/sjp38/lazybox/blob/master/cve_stat/cves_per_file.py

Just tagged and pushed hackermail v1.0.1[1]. The most important change in this version would be the support of remote synchronization[2].

[1] https://github.com/sjp38/hackermail/blob/v1.0.1/release_note
[2] https://github.com/sjp38/hackermail/blob/v1.0.1/USAGE.md#synchronizing

#hackermail #hkml

@spmatich IIRC, the Linux CNA team mentioned they will not give CVSS to new CVEs. I guess that's the reason. I don't find the link, though.

@Issa I didn't scan any kernel. Instead, I scanned others' kernel scan results :) You could use the source of the script for detail.

I just renewed my subscription to @LWN

The best content about bleeding-edge Linux kernel development! 🐧 🙌

You should really consider subscribing if you haven't done it yet. 🙂

@authentic_sammj I have no opinion but only a humble script :)

@Issa For more context, I believe this great LWN article could be very helpful: https://lwn.net/Articles/961978/

@Issa I cannot confirm since my script may have bugs ;) What the script argues is that about 450 (exact number is 440) security bugs for upstream-supporting Linux kernels are identified and got their official identifiers (CVE) within last 30 days.

I wanted to know simple daily Linux kernel CVE statistics just for fun, so wrote a script[1] and plotted the output.

$ ./vulns_stat.sh ./vulns/ 30 | ../gnuplot/plot.py --data_fmt table --type labeled-lines --xtics_rotate -90 cve_stat_30_days.png

[1] https://github.com/sjp38/lazybox/blob/master/cve_stat/vulns_stat.sh

#linux #kernel #cve #stat

Oops, I should have read replies to Thorsten's post before writing mine...

Inspired by Thorsten's great rc8 statistic[1], I extended my script[2] to further expect future releases based on the past release cadence.

[1] https://social.kernel.org/notice/AfkOGGMJWyDFsvYXdA
[2] https://github.com/sjp38/lazybox/blob/master/git_helpers/relstat.py

#linux #kernel #release_stat

Memory management subsystem pull request[1] for Linux 6.9-rc1 has been posted. To quote Andrew’s summary for DAMON part:

• More DAMON work from SeongJae Park in the series
  • “mm/damon: make DAMON debugfs interface deprecation unignorable”
  • “selftests/damon: add more tests for core functionalities and corner cases”
  • “Docs/mm/damon: misc readability improvements”
  • “mm/damon: let DAMOS feeds and tame/auto-tune itself”

[1] https://lore.kernel.org/all/20240313200532.34e4cff216acd3db8def4637@linux-foundation.org/

#linux #kernel #damon

The 6.8 kernel has been released https://lwn.net/Articles/964784/ #LWN

@ljs @kernellogger @larsmb @gregkh @pavel It's really complicated... I'm myself on the distro side here (though speaking only for myself) and I see very clearly the additional work that this is causing. On the other hand... I do think this is actually moving things in the right direction, security-wise. The uncomfortable truth is that the kernel has a TON of bugs, many with security impact. This move really just puts it completely out in the open and forces everybody to acknowledge that fact.

Just got an invitation to LSF/MM/BPF 2024[1]. Looking forward to meeting with other kernel hackers and discuss about topics for DAMON[2] and memory management!

[1] https://events.linuxfoundation.org/lsfmmbpf/
[2] https://lore.kernel.org/damon/20240129204749.68549-1-sj@kernel.org/

#linux #kernel #damon #lsfmm #lsfmmbpf

Just released damo (DAMON user-space tool) v2.2.4[1]. This version enables access pattern-based profiling[2]. For example, you can know which code is making your program's memory usage unexpectedly high, or which code is intensively accessing memory. Hopefully that will help better understanding and optimizing your code.

[1] https://github.com/awslabs/damo/tree/v2.2.4
[2] https://github.com/awslabs/damo/blob/v2.2.4/USAGE.md#profile

#linux #kernel #damon #damo #profiling

@kernellogger @kees @gregkh I also considered using the repo, especially the nice json files under cve/published/. However, the README[1] under cve/ made me hesitate. Quoting the part that made me unsure if it can be used.

For now, ignore this as we are getting things working properly…

[1] https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/README

Yet another academic paper[1] exploring DAMON for tiered memory management will be presented at EuroSys 2024[2].

[1] https://pasalabs.org/papers/2024/Eurosys24_M3_Camera_Ready.pdf
[2] https://2024.eurosys.org/

#linux #kernel #damon #eurosys

The #Linux #kernel CVE team released their first two CVEs:

* CVE-2023-52433: netfilter: nft_set_rbtree: skip sync GC for new elements in this transaction
https://lore.kernel.org/linux-cve-announce/2024022058-outsell-equator-e1c5@gregkh/

* CVE-2024-26581: netfilter: nft_set_rbtree: skip end interval element from gc
https://lore.kernel.org/linux-cve-announce/2024022024-uniquely-recluse-d893@gregkh/

For more details on the new #LinuxKernel CVE process, see https://docs.kernel.org/process/cve.html (recently added by https://git.kernel.org/torvalds/c/5928d411557ec5d53832cdd39fc443704a3e5b77 )

Screenshot from https://lore.kernel.org/linux-cve-announce/

DAMO v2.2.2 is released. The important change in this release is the introduction of 'replay' command[1]. It receives 'damo record' output and replay the recorded access pattern. Hopefully it will help reproducing the real-world's memory access pattern for analysis and benchmarks. The command is in an experimental level and not formally documented at the moment, though.

[1] https://github.com/awslabs/damo/blob/v2.2.2/release_note#L5

#linux #kernel #damon #damo