In the Linux kernel, the following vulnerability has been resolved: tls: always refresh the queue when reading sock After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry. BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls] (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529 CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasan_report+0xca/0x100 tls_strp_check_rcv+0x898/0x9a0 [tls] tls_rx_rec_wait+0x2c9/0x8d0 [tls] tls_sw_recvmsg+0x40f/0x1aa0 [tls] inet_recvmsg+0x1c3/0x1f0 Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len").
| Product | Vendor | Version |
|---|---|---|
| Linux | Linux | IPQ4019, IPQ8064, IPQ8074, MDM9206, MDM9607, MDM9635M, MDM9640, MDM9650, MSM8996AU, QCA6174A, QCA6564, QCA6574, QCA6574AU, QCA6584, QCA6584AU, QCA9377, QCA9378, QCA9379, QCA9531, QCA9558, QCA9563, QCA9880, QCA9886, QCA9980, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 600, SD 625, SD 650/52, SD 820, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM630, SDM632, SDM636, SDM660, SDM710, SDX20, Snapdragon_High_Med_2016 |
| Linux | Linux | n/a |
| Linux | Linux | 9.0.1 |
| Linux | Linux | 8.0.0.7 |