みなさんこんにちは。私のプレゼンテーションに感謝します。タクマカワイの名前は、ミラクシアエジテクノジーコープライションのタクマカワイです。今日は、リアクスカーネブラウナビティを話します。エンベルトリアクスのコープライトのCPEsearch メソドは新しいソフトアップデートに使用されています。CPEsearch メソドは、作成やバレナリブ イ procedure メソデーションのコープアップデートに使用するプラゼンテーションのシスト メソドでリアクスを作ったコープライトのCPEsearch メソドでローコンフォースをわかるためにコープライトのシステムに使用されています。システムにはタクマカワイは手で買い物を追加することができます。このタイミングは、CBIDの数字を追加することができます。CBIDを追加することができます。Xcarnel 4.14.296 is the latest long-term support version released in October 2022.and the others are released in 2018.So, even though it's the latest version, so many CBIDs are found.However, because it's the latest version, most of them are false positives.I will explain why so many false positives are being reported.When we develop software updates, we search for CBIDs by CBsearch and then manually investigate our platform is affected by CBID or not.However, most of CBIDs detected for the Xcarnel are false positives.In a typical situation, 50% to 90% are false positives.There are two main reasons for false positives.The first reason is that our Xcarnel version is out of range of vulnerable version.The second reason is that the vulnerable code is not built with our configuration.In this talk, I will show you how false positives are reported and how to automate the determination of false positives.By automating the determination of false positives, we can reduce the manual investigation by 50% to 90% compared to the traditional method.I will explain the first problem.The first problem is that the version numbers registered in the nvd are too rough.For most cb, react cb records, only the major version that fixed the security issue is registered to the nvd.As an example, this figure illustrates a vulnerability fix in 5.17.In the above figure, the red line shows the range of vulnerable versions determined by the CBsearch2.In the lower figure, the red line is the actual version range contains the vulnerable code.In this example, the fix for the version 5.17 is backported in version 5.15.7.However, the cbsearch2 incorrectly reports versions prior to 5.17 as vulnerable, including all versions of the stable branches.This is an example cb record of relux kernel.Versions smaller than 5.18.4 are affected according to this cb record.The cbsearch2 looks at this record and determines that all major versions smaller than 5.18and all versions of the stable branches are affected.This problem can be solved by using the Ubuntu cv tracker data.The Ubuntu cv tracker records the commit IDs that introduced and fixed the bugs for each cbe.I call these commits break, commit, and fix commit.The Ubuntu cv tracker records break fix commits on master branch to find out the version range in a stable branch.We need the backported commit ID in the stable branch.I need this one, but Ubuntu cv tracker provides this one and this one.Almost all commits in stable branch are cherry picked from master branch.According to the stable kernel maintenance rules,the upstream commit ID should be included in the commit message, like this.Comet share one upstream.Now we know the fixed commit in the master branch.Is this okay? Thanks.Now we know the fixed commit in the master branch.We can search the stable branch with that commit ID to find the fixed commit in the stable branch.I will show an example procedure that you can actually perform in the data section.You can find a practically like expression in the CIP project repository that looks up cherry picked commit IDs.By using this, you can find the upstream commit for almost every commit in the stable branch.I will now discuss the second problem with CPE search.The second problem is that the Linux kernel is too large.Most of the source code is not compiled in a build configuration optimized for a specific platform.On the other hand, CPEs are registered as a single product for the entire Linux kernel.I analyzed the difference CPE Tucker and categorized the Linux kernel vulnerabilities.Most CPEs are related to architecture implementation and drivers.We optimized our build configuration for specific hardware, so you know most CPEs have not built.I introduced a tool called coverage.Coverage start with K, not C.Coverage is a part of the Kmax tool suite.With this tool, you supply a pair of file name and line number.You can check if this will be compiled or not.Supply kernel tree and .conf file and patch file to the coverage command.You can check if the patch will be compiled or not.If the break command doesn't build, we can check.We can determine that our platform is not affected by the CPE.Using the coverage command for this purpose requires a tweak.Because the coverage command is based on line numbers,we need to fix the hanko set of the patch.This is done by without the patch twice.Like this.I present an example CPE Toriage flow.As an example, I will examine CPE 2021 45480.First, we check the Ubuntu CPE Tucker for break fix commands.This is an example Ubuntu CPE information.This is an example Linux CPE information in the Ubuntu CPE Tucker.At the top is information imported from NBD.This area is from NBD.And comments from the Ubuntu CPE security chain.This is the comments from Ubuntu CPE security chain.The break fix commands are in this case defined at line 33.The left commit ID is break commit and the right one is fix commit.Both are on the master branch.Next, we identify the version range affected by the CPE.We can pass the break fix commits to thelit.contains command to find out the major version fix the CPE.In this example, the issue was introducing 5.13and fixing 5.16.If you are using 5.15 branch,you have to identify the version in the branch that fixed the CPE.Because 5.15 is still maintained.CPE fix in the master branch are basically back ported.So, you can supply the fix commit to thelit.contains command to identify the fix commit in therelax 5.15.y branch.then do as same as previous.You can identify the version fixed to the CPE in the stable branch.In this example, the CPE was fixed in 5.15.11.If your kernel version is affected by the CPE,you should check if the break commit is compiled.Firstly, you need to fix Hancock setby reverting the break commit twice here.Then execute coverage commandwith.config file and patch file.This is an example report generated by coverage.For every modified line by the patch,it reports if the line is compiled or not.If all lines are 5 excluded orline excluded 5 included,you can determine that your kernel is not affected by the CPE.Finally, I present some benchmarks.I took this benchmark a month ago.I first generated a CPE list using CPE searchand classified the CPEs.The total height from here to hereis the number of CPEs detected by the CPE search too.And green area from here to herethey are false positives.This is the benchmark resultsof the latest long term support kernel.The green and light yellow areafrom here to hereare CPEs identified as false positives.And in all cases, more than 80%,this is all more than 80%for identified as false positives.It's not surprising thatalmost all are false positives.Because this is the latest version,all CPE front bugs are fixed.All the versions have more CPEs reportedbecause only major versions are recorded to the NVD.So the CPE search tool reportsalmost identical CPEs for4.14 and 4.14.296.The orange area, this areaare marked as positive.These were ignored in the stable branch.CPEs are ignored in casethey are incorrect orconsidered not serious.I did the same researchwith the latest versionand older versionsof the step 5.4 branch.I chose the versionso that release datesare about a year apart.5.4.221October 2022and 160November 2021and 80November 2020The dark green and light yellow areafrom here to hereare determined not to be compiled.Light yellow area, this areaare identified as false positivesin both methods.I used the default configurationfor the previous versionof the step 5.4.I used the default configurationfor the previous versionof the step 5.4.I used the default configurationforarm64.The CPE size 2 reportsalmost identical CPEsfor the same stable branch releases.This is becausethe most CPEsare only registered withmeasure versions to the MVD.In this exampleabout 20%are detected as not compiled.In this approachthe number of CPEsdetectednot to be compiledis depend on thepre-commit and .confso if the CPE listis the sameas the set ofpre-commit and .confso if the CPE listis the sameset ofpre-commit is the samethen number of false positiveswill be the same.For all versionsof the 5.4.branchthe arm64default configurationwill result in20% false positives. Conclusionfor the latest long term supportcarnia,SOSserious bugs are fixedbutthe CPE search tool reportshundreds of false positives.This is caused bythe low quality datafrom the MVD.Most CPEscan be determined asfalse positives by usingthe Ubuntu CV tracker data.For all the kernelsabout 20%of the CPEscan be determined asfalse positivesconsidering.conf filethat's all from me.Any questions?What does the color meanin your graph?YeahI categorize the CPEsasthree categories.One isfalse positivesdetermined bycommuter IDsand second one isfalse positives determined byconf fileand the othersandyellow area isdetermined byfalse positivesby both method.What method?I first recheckedin this casewe are using5.15.10for exampleI using 5.15.10sofirstlyI have to determinethe version rangethat is affected by the CPEin mainlineso in this casein mainlineby wasintroduced in 5.13and5.16this versionthe mainline versionsonow I'm using5.15 branch5.15.10for examplesothis is an exampleillustrationsoI'm using 5.15.10maybe this onesothe fixed commit is backported inthis onesoif I'm usingthis or thiswe must fixCPEbut if we are using this oneyou don't needto fix CPEsofirstly we have to checkthe actual version rangeaffected by the CPEthenonce if yourealizethat yourcarnal version is affected by the CPEbutyour configuration could benot compiledsowe checkthe break commitis compiled or notsoas third stepI checkthe break committhis oneis compiled or notsothe commit graphrepresents thatthis areathe right viewingrepresents thatforce positivesdetermined by the second stepthe hand step isthis oneandthe right yellow andright green areathis arearepresents thatforce positivesdetermined by the third stepthis onethank youno questionno questionthank you for coming to my presentation