In the Linux kernel, the following vulnerability has been resolved:
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer
The reproduction steps:
1. create a tun interface
2. enable l2 bearer
3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode
tipc: Node identity 8af312d38a21, cluster identity 4711
tipc: Enabled bearer <eth:syz_tun>, priority 1
Oops: general protection fault
KASAN: null-ptr-deref in range
CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT
Hardware name: QEMU Ubuntu 24.04 PC
RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0
the ub was in fact a struct dev.
when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or
other media when other thread changes it.
fix this by checking media_id.
CVSS
7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
from 832629ca5c313e122b22b8e73a6d80f111b1a1ae before 3998283e4c32c0fe69edd59b0876c193f50abce6; from 832629ca5c313e122b22b8e73a6d80f111b1a1ae before c2e17984752b9131061d1a2ca1199da2706337fd; from 832629ca5c313e122b22b8e73a6d80f111b1a1ae before 8595350615f952fcf8bc861464a6bf6b1129af50; 832629ca5c313e122b22b8e73a6d80f111b1a1ae builds before 05d332ba075753d569d66333d62d60fff5f57ad8; from 832629ca5c313e122b22b8e73a6d80f111b1a1ae before d3dfe821dfe091c0045044343c8d86596d66e2cf; 832629ca5c313e122b22b8e73a6d80f111b1a1ae builds before 0d3d91c3500f0c480e016faa4e2259c588616e59; 832629ca5c313e122b22b8e73a6d80f111b1a1ae builds before 0f4a72fb266e48dbe928e1d936eab149e4ac3e1b; from 832629ca5c313e122b22b8e73a6d80f111b1a1ae before f82727adcf2992822e12198792af450a76ebd5ef
from 4.9 before 5.4.295; from 5.5 before 5.10.239; from 5.11 before 5.15.186; from 5.16 before 6.1.142; from 6.2 before 6.6.95; from 6.7 before 6.12.35; from 6.13 before 6.15.4; 6.16; and 1 more ranges
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.