Linux Kernels 5.4.5 and 5.3.18 Are Released With Security-Related Networking Fixes
The new stable-kernel versions 5.4.4 and 5.3.17 were released on Tuesday. Then the kernel developers decided to release yet another minor version late Wednesday - just a day after the prior release. This tends to happen when there is an urgent need to fix a security issue. A close-up inspection of the patch-set between 5.4.4/5.4.5 and 5.3.17/5.3.18 reveals that a lot of corner-case network-related issues were ironed out in the latest kernel releases.
written by 윤채경 (Yoon Chae-kyung) 2019-12-19 - last edited 2019-12-20. © CC BY
One of the changes to net/core/page_pool.c between kernel 5.3.17 and 5.3.18. One does not simply reference a already-released memory pool.
The 5.3.x kernels series is declared End-Of-Life (EOL) as of 5.3.18 which is quite sad since 5.4.x and 5.5-rc2 have a plain broken i915 module which cases crashes and hangs. This was true for 5.3 series kernels up to 5.3.13 too. That leaves the long-term supported kernel series 3.16.x, 4.4.x and 4.19.x as well as the newer 5.4.x series kernels as "supported".
The changes between 5.3.17/5.3.18 and 5.4.4/5.4.5 are in the network subsystem and the network drives for Infiniband and Mellanox network gear. They appear to be security-related in nature. That is frequently the case when a minor kernel version is released a day or two after a previous kernel version.
One change in particular stands out: tcp: md5: fix potential overestimation of TCP option space which is described by Googles kernel developer Eric Dumazet as:
"Back in 2008, Adam Langley fixed the corner case of packets for flows having all of the following options : MD5 TS SACK
Since MD5 needs 20 bytes, and TS needs 12 bytes, no sack block can be cooked from the remaining 8 bytes.
tcp_established_options() correctly sets opts->num_sack_blocks to zero, but returns 36 instead of 32.
This means TCP cooks packets with 4 extra bytes at the end of options, containing unitialized bytes."
How much a hostile attacker could do with a stream of packets with 4 bytes of potentially previously used memory is limited.
Many of the other fixes relate to crashes in peculiar network configurations. net: bridge: deny dev_set_mac_address() when unregistering is described as fixing:
"We have an interesting memory leak in the bridge when it is being unregistered and is a slave to a master device which would change the mac of its slaves on unregister (e.g. bond, team)."
A crash could be triggered by doing something similar to these steps:
- add bond in mode != A/B
- add any slave to the bond
- add bridge dev as a slave to the bond
- destroy the bridge device
Why anyone would do that in a real-world deployment is beyond our understanding. That goes for another fix in these kernels titled inet: protect against too small mtu values. which fixes a problem where:
" syzbot was once again able to crash a host by setting a very small mtu on loopback device.
Let's make inetdev_valid_mtu() available in include/net/ip.h, and use it in ip_setup_cork(), so that we protect both ip_append_page() and __ip_append_data()
Also add a READ_ONCE() when the device mtu is read."
The rest of the network-related patches appear to address similar corner-cases.
The biggest issue addressed in these new kernels appear to be the minor problem of TCP streams with the MD5, TS and SACK flags set getting 4 extra bytes at the end of each packet. It is an issue but we can't see what any hostile attacker would be able to do with that. Lots of packets with 4 bytes adds up but it's not like an attacker would get a continuous memory region. System administrators running very complex setups may want to upgrade to these latest kernels anyway.
The new kernels are, like always, available from kernel.org.
Enable comment auto-refresher