Hello, I am K, and as a Red Hat contributor in my hobby, um I'm working on some security things in my office. I'd like to share my experiences and lessons learned from the Red Hat vulnerability reporting process and Red Hat Bugzilla. I will explain what it means for the

Red Hat to become a CNA and what I have experienced after CNA. Also, I will introduce the cicolor Bugzilla tool that has been extremely helpful in finding Red Hat vulnerabilities. Now, shall we talk about Red Hat CNA and CVE?

The Red Hat project became a CVE Numbering Authority (CNA) this year. Now, Red Hat's CVE team can directly assign CVE numbers. CVEs are assigned only after patches are released. The Red Hat CVE team has been assigning CVEs to bug fixes with careful

review. Vulnerability tracking is managed through a dedicated Git repository. This works to ensure more transparent security information for all Linux users. This is the repository address. Now, this is the redhat.com repository that manages Red Hat vulnerabilities, which I just explained in the previous slide, for those

interested in Red Hat development. We can see the names of notable Red Hat maintainers, Greg and Shash Rine, and their collaborative works in here. Looking at these common logs, you can see the review process for applied potential security patches is really

active. While observing the Red Hat CVE team's work, I noticed they follow this main process: proposed CVE announcement. The CVE team's documented process shows how vulnerability patches are reviewed and tracked for each version. Patches are organized into two sections: proposed patch under review

and complete patches in the dawn directory once the CB team completes their review they publish the patch and each assigned CB number to the mailing list the Rux Con CB announcements are published on the following mailing list address r.con.org Linux CB announ the right image

shows the mailing list filtered for s390 architecture you can see the two series I discovered I will explain this in more detail later slide this is some subscribing mailing list address let's explore how to find and Report Rux Conner vulnerabilities through the official Rux Conner security check

s the Conor security documentation explain the reporting process with this highlighted word it follows standard Pat submission but needs comprehensive details about the vulnerabilities I've learned a lot from two excellent resources created by respected Conor security researchers the and Google security team that offers valuable guidance of

this process I will share my journey of reporting my CB first and second Conor security bug including the challenges I faced while using a corner fer actually un Corner security um more related to user privilege in the context not the privilege context in the control playe

bug more us the plane bug this is first CB I've received this year late to the ud FD with UD FD poison when we utilizing this feature we can crash the ibmg renux system former mitigated version with user privileges this is my security report I

included as much detail as possible in my analysis but then lonus replied correcting my misunderstanding and providing a more general explanation in fact this is the first email I've received from lus cheers lonus refer to C color as a reproducer which we can discuss follow

further in the S color chapter he also shared a patch that prevents this crash issue.  Lus encouraged the involvement of people who are maintaining the subsystem s390 x390 architecture.  And then IBM maintainer Gerard replied with a detailed analysis with mitigation patch he had.

some brench code so I tested it with the same scenario and Gerald's patch successfully prevented this corner crash. I also asked questions about what I didn't understand.  Gerald provided more detailed explanations and directly questioned Lus and Greg as part of the normal B fix.

process. PR then GRE mentioned that this normal BG will receive a CB CBE cheers. So this is the CB announcement for this issue. The patch was applied but there was a gap of what two weeks before the announcement. This delay allowed for the back-porting to various

distributions. This is another CV that I discovered. This is also a crashy issue that a normal user can trigger in the IBM s390 architecture. The cornal code has trouble with an assumption that is not possible, but certain corner options can break this

assumption. This is the cor stch and there was a missing check for the memory page flag in the IBJ architectures memory management subsystem. Lonus also replied regarding this patch. He described it as a regular bug which refers to a programmatic oversight. This

is not a difficult bug that requires re-writing a subsystem. So the IBM s390 M maintainer fixed this code with a detailed patch message. Thank you, Heyo. So I tested it again with m a patch applied and this patch successfully prevented the crash. I

discovered finally the CV has been announced cheers I will introduce the L Corner folder let's get started what is Corner for the Corner uses system CES to connect user and Corner space and handle device communication through Network and Hardware protocols KOB provides code coverage information

for forging for each system core or collecting remote coverage information from Corner threads or soft IRQ context this feature maximizes testing effectiveness and Corner debugging features provide powerful tools for finding operations offering detailed bug detection with analyzable crash data Additionally Corner sanitizer uses

compiler features to detect runtime memory bugs and race conditions this is uh what is this Corner this is an automated system continuously testing the Corner while managing an efficient collection of the test cases from main code coverage you can refer to the link provided later for hands-on practice

this has this tool has a key Point interface based test generation smart Corpus management comprehensive crash analysis this is a bird's eye view of how Corner operates when C manager is executed on the management machine it runs finding processes on the target machine the folder management system collects the

and manages all the information generated during the finding process so this is the management process from the management machine and this is the target finding process this is the configuration files is read by C manager to control and manage the target machine this target machine a QEMU virtual

machine on 64 bit Linux runs three finding processes specifically testing SMB file system code by filtering coverage to fs/smv files and KMD functions restricting finding to only to CIS here is one CIS right in enable code coverage tracking for better finding

efficiency uses a single fing Target BM instance with four CPU cores and 4 GB of memory enable kbm acceleration and use host CPU model. This runs on my Raspberry Pi 5 in my home. We can fing Target with user mode with this

options here is the option about privilege and semi mode running as user, no body names space mode requiring configuration on the user ends in corner configuration. Corner folding helps companies comply with compliance requirements while avoiding penalty and reputation risk. As you know, SH has

some penalty fees. This is some this is a big deal, right? So this contributes to the company's product stabilities. Setting the sandbox to know allows operation with root privileges. This helps find many bugs, double for corner contribution. Bug fixing is meaningful work in itself as an open-source

contribution, right? And it's essential for becoming a ruxtype plumber. It is important to thoroughly check the mailing list for any existing related patching in the specific subsystem tree before proceeding. Corner folding using S color can be performed on isolated, immediate

systems with specific hardware configuration with P store. How is Google using it? Let's see Google's usage of C color through their dashboard and C color mailing list which show how they manage corner testing and bug reporting. This is the address of C Upstream dashboard and this is the

mailing list. Some of the development next bridge R stable BPF and some Google related branch. And this is open issue. So many bugs in here, right? We can see there are many corners on this dashboard, such as x86 risk 5, AR 64 with Google computer engine.

configuration oh there are so many new things right this is now and just a minute right so how can we for it these are the architectures I've worked with but there are still many architectures I haven't explored yet so I checked this sanitizer option can

enable in this architecture so we need to build some corner with the configuration and we need to some virtual machine QEMU KVM enabled or host CPU preferred because it's fast and prepare root file system I tested Yoko framark and also some Ubuntu Fedora image

within and we need some SSH key file so Google tested it with configuration so this is the first Dev configuration we we need Dev configuration right so there's some Dev configuration in Fedora and SSH dashboard with .config this is the dashboard of C-color

we can find corpus coverage supported the sces and crash this is reproduced bug SNP process ID in printable code in event function C this is patched last ring corner version so this is some generated reproducible bug this is a COR log from

this page this page Rog report this corner B that crash occurred we can we can see the parf event this is the C length log from each corpus made uh C-color makes some mutate some input this is the each system call and pH color make some arbitrary input for

this S system call how can we reproduce it we can reproduce in the Target motion with see exact Pro and scenario R made from the corpus with this previous slide additionally we can make source code from the previous C Lang log filtering testing to focus on

specific system core or device files. This is some tips when we're learning Cal t-marks, using t-marks for session liveness, and we prefer some best options in QMU. And this is some tip: sufficient disk size, etc. We can find information with col

source code, some filtering on the configuration file, make effective finding the Reus Corner PES, specify low P table file name. Each line of the file should be this format. We can have the C col to make more foring other corner programs or brand new corner

module. This is important: physical color needs some physical descriptions and pseudo system code. So I made it for the finding the KMBd subsystem, so C KMBd S W and S color will mutate this input in here, and this pseudo system code that input

the mutated argument from the C color. This is the C code that mapping with this, and I added the P system code in Lis score. Go file in S color. Let's review what I said first time, do you a little bit more clear about security reporting in this session?

If you didn't talk with me in other channels, and let's discuss more on this. I prepared some of my mistakes I encountered, encountered during my first attempt at security BG reporting. This patch has had several problems when we reproduce all this bug. We need root

privileges. This is an app Trace related bug according to Greg's feedback. There's a several issues with this security report: security mail and CB report should not be combined. The patch needs a fixed tag. The reported bug requires root privileges and are control plane issues.

that don't directly impact the system security and other try and error. I reported this bug through the following patches. The issue involves a double-free memory bug caused by a synchronization problem. According to Greg's feedback, security and CM should be kept separate, so secur.corner.org is a private mail

that's not publicly opened. Additionally, the following cases are unlikely to be considered security vulnerabilities: patches still in progress, Bluetooth issues that are in R-next, bugs requiring complex conditions that are difficult for regular users to reproduce, control bugs requiring elevated

privileges like root. That don't directly impact system security, fixing Corner warnings is good, but I recommend looking at the broader context of the subsystem. Simply focusing on the specific code for the security purpose without considering the context can be shortsighted. This is the summary in my session.

Thanks again for joining my session. Thank you.

Head First Reporting of Linux Kernel CVEs Practical Use of the Kernel Fuzzer Yunseong Kim, Open Up

Head First Reporting of Linux Kernel CVEs Practical Use of the Kernel Fuzzer Yunseong Kim, Open Up