{"id":180,"date":"2019-02-14T14:54:00","date_gmt":"2019-02-14T14:54:00","guid":{"rendered":"https:\/\/opstree.com\/blog\/\/2019\/02\/14\/my-stint-with-runc-vulnerability\/"},"modified":"2020-08-11T11:19:06","modified_gmt":"2020-08-11T05:49:06","slug":"my-stint-with-runc-vulnerability","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2019\/02\/14\/my-stint-with-runc-vulnerability\/","title":{"rendered":"My stint with Runc vulnerability"},"content":{"rendered":"

Today I was given a task to set up a new QA environment. I said no issue should be done quickly as we use Docker, so I just need to provision VM run the already available QA ready docker image on this newly provisioned VM. So I started and guess what Today was not my day<\/b>. I got below error while running by App image.<\/p>\n

docker: Error response from daemon: OCI runtime create failed: container_linux.go:344: starting container process caused “process_linux.go:293: copying bootstrap data to pipe caused \\”write init-p: broken pipe\\””: unknown.<\/p><\/blockquote>\n

I figured out my Valentine’s Day gone for a toss. As usual I took help of Google God<\/b>\u00a0to figure out what this issue is all about, after few minutes I found out a blog pretty close to issue that I was facing<\/p>\n

https:\/\/medium.com\/@dirk.avery\/docker-error-response-from-daemon-1d46235ff61d<\/a><\/p><\/blockquote>\n

Bang on<\/b> I got the issue identified. There is a new runc vulnerability<\/b> identified few days back.<\/p>\n

https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2019-5736<\/a><\/p><\/blockquote>\n

The fix of this vulnerability was released by Docker on February 11, but the catch was that this fix makes docker incompatible with 3.13 Kernel version.<\/p>\n

While setting up QA environment I installed latest stable version of docker 18.09.2<\/i> and since the kernel version was 3.10.0-327.10.1.el7.x86_64<\/i>\u00a0thus docker was not able to function properly.<\/p>\n

So as suggested in the blog I upgraded the Kernel version to 4.x<\/b>.<\/p>\n

rpm –import https:\/\/www.elrepo.org\/RPM-GPG-KEY-elrepo.org
\nrpm -Uvh http:\/\/www.elrepo.org\/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
\nyum repolist
\nyum –enablerepo=elrepo-kernel install kernel-ml
\nyum repolist all
\nawk -F\\’ ‘$1==”menuentry ” {print i++ ” : ” $2}’ \/etc\/grub2.cfg
\ngrub2-set-default 0
\ngrub2-mkconfig -o \/boot\/grub2\/grub.cfg
\nreboot<\/p><\/blockquote>\n

And here we go post that everything is working like a charm.<\/p>\n

So word of caution to every even<\/b>
\nWe have a major vulnerability in docker CVE-2019-5736<\/b>, for more details go through the link<\/p>\n

https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2019-5736<\/a><\/p><\/blockquote>\n

As a fix, upgrade your docker to 18.09.2<\/b>, as well make sure that you have Kernel 4+<\/b> as suggested in the blog.<\/p>\n

https:\/\/docs.docker.com\/engine\/release-notes\/<\/a><\/p><\/blockquote>\n

Now I can go for my Valentine Party \ud83d\udc6b<\/p>\n","protected":false},"excerpt":{"rendered":"

Today I was given a task to set up a new QA environment. I said no issue should be done quickly as we use Docker, so I just need to provision VM run the already available QA ready docker image on this newly provisioned VM. So I started and guess what Today was not my … Continue reading “My stint with Runc vulnerability”<\/span><\/a><\/p>\n","protected":false},"author":159857435,"featured_media":29900,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[1],"tags":[768739308,676319247,768739305,85247986],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2025\/11\/DevSecOps-1.jpg","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pfDBOm-2U","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/180"}],"collection":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/users\/159857435"}],"replies":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/comments?post=180"}],"version-history":[{"count":4,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/180\/revisions"}],"predecessor-version":[{"id":3878,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/180\/revisions\/3878"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media\/29900"}],"wp:attachment":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media?parent=180"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/categories?post=180"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/tags?post=180"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}