Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cu_tx_fill_desc()<br /> <br /> TID getting from ieee80211_get_tid() might be out of range of array size<br /> of sta_entry-&gt;tids[], so check TID is less than MAX_TID_COUNT. Othwerwise,<br /> UBSAN warn:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30<br /> index 10 is out of range for type &amp;#39;rtl_tid_data [9]&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> e1000: fix OOB in e1000_tbi_should_accept()<br /> <br /> In e1000_tbi_should_accept() we read the last byte of the frame via<br /> &amp;#39;data[length - 1]&amp;#39; to evaluate the TBI workaround. If the descriptor-<br /> reported length is zero or larger than the actual RX buffer size, this<br /> read goes out of bounds and can hit unrelated slab objects. The issue<br /> is observed from the NAPI receive path (e1000_clean_rx_irq):<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790<br /> Read of size 1 at addr ffff888014114e54 by task sshd/363<br /> <br /> CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5a/0x74<br /> print_address_description+0x7b/0x440<br /> print_report+0x101/0x200<br /> kasan_report+0xc1/0xf0<br /> e1000_tbi_should_accept+0x610/0x790<br /> e1000_clean_rx_irq+0xa8c/0x1110<br /> e1000_clean+0xde2/0x3c10<br /> __napi_poll+0x98/0x380<br /> net_rx_action+0x491/0xa20<br /> __do_softirq+0x2c9/0x61d<br /> do_softirq+0xd1/0x120<br /> <br /> <br /> __local_bh_enable_ip+0xfe/0x130<br /> ip_finish_output2+0x7d5/0xb00<br /> __ip_queue_xmit+0xe24/0x1ab0<br /> __tcp_transmit_skb+0x1bcb/0x3340<br /> tcp_write_xmit+0x175d/0x6bd0<br /> __tcp_push_pending_frames+0x7b/0x280<br /> tcp_sendmsg_locked+0x2e4f/0x32d0<br /> tcp_sendmsg+0x24/0x40<br /> sock_write_iter+0x322/0x430<br /> vfs_write+0x56c/0xa60<br /> ksys_write+0xd1/0x190<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f511b476b10<br /> Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24<br /> RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10<br /> RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003<br /> RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00<br /> R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003<br /> <br /> Allocated by task 1:<br /> __kasan_krealloc+0x131/0x1c0<br /> krealloc+0x90/0xc0<br /> add_sysfs_param+0xcb/0x8a0<br /> kernel_add_sysfs_param+0x81/0xd4<br /> param_sysfs_builtin+0x138/0x1a6<br /> param_sysfs_init+0x57/0x5b<br /> do_one_initcall+0x104/0x250<br /> do_initcall_level+0x102/0x132<br /> do_initcalls+0x46/0x74<br /> kernel_init_freeable+0x28f/0x393<br /> kernel_init+0x14/0x1a0<br /> ret_from_fork+0x22/0x30<br /> The buggy address belongs to the object at ffff888014114000<br /> which belongs to the cache kmalloc-2k of size 2048<br /> The buggy address is located 1620 bytes to the right of<br /> 2048-byte region [ffff888014114000, ffff888014114800]<br /> The buggy address belongs to the physical page:<br /> page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110<br /> head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0<br /> flags: 0x100000000010200(slab|head|node=0|zone=1)<br /> raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000<br /> raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> ==================================================================<br /> <br /> This happens because the TBI check unconditionally dereferences the last<br /> byte without validating the reported length first:<br /> <br /> u8 last_byte = *(data + length - 1);<br /> <br /> Fix by rejecting the frame early if the length is zero, or if it exceeds<br /> adapter-&gt;rx_buffer_len. This preserves the TBI workaround semantics for<br /> valid frames and prevents touching memory beyond the RX buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: asix: validate PHY address before use<br /> <br /> The ASIX driver reads the PHY address from the USB device via<br /> asix_read_phy_addr(). A malicious or faulty device can return an<br /> invalid address (&gt;= PHY_MAX_ADDR), which causes a warning in<br /> mdiobus_get_phy():<br /> <br /> addr 207 out of range<br /> WARNING: drivers/net/phy/mdio_bus.c:76<br /> <br /> Validate the PHY address in asix_read_phy_addr() and remove the<br /> now-redundant check in ax88172a.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly<br /> <br /> The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a<br /> LS_NLA_TYPE_DGID attribute, it is invalid if it does not.<br /> <br /> Use the nl parsing logic properly and call nla_parse_deprecated() to fill<br /> the nlattrs array and then directly index that array to get the data for<br /> the DGID. Just fail if it is NULL.<br /> <br /> Remove the for loop searching for the nla, and squash the validation and<br /> parsing into one function.<br /> <br /> Fixes an uninitialized read from the stack triggered by userspace if it<br /> does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE<br /> query.<br /> <br /> BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]<br /> BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490<br /> hex_byte_pack include/linux/hex.h:13 [inline]<br /> ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490<br /> ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509<br /> ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633<br /> pointer+0xc09/0x1bd0 lib/vsprintf.c:2542<br /> vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930<br /> vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279<br /> vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426<br /> vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465<br /> vprintk+0x36/0x50 kernel/printk/printk_safe.c:82<br /> _printk+0x17e/0x1b0 kernel/printk/printk.c:2475<br /> ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]<br /> ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141<br /> rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]<br /> rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]<br /> rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]<br /> netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346<br /> netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> __sock_sendmsg+0x333/0x3d0 net/socket.c:729<br /> ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671<br /> __sys_sendmsg+0x1aa/0x300 net/socket.c:2703<br /> __compat_sys_sendmsg net/compat.c:346 [inline]<br /> __do_compat_sys_sendmsg net/compat.c:353 [inline]<br /> __se_compat_sys_sendmsg net/compat.c:350 [inline]<br /> __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350<br /> ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306<br /> do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: Fix reference count leak when using error routes with nexthop objects<br /> <br /> When a nexthop object is deleted, it is marked as dead and then<br /> fib_table_flush() is called to flush all the routes that are using the<br /> dead nexthop.<br /> <br /> The current logic in fib_table_flush() is to only flush error routes<br /> (e.g., blackhole) when it is called as part of network namespace<br /> dismantle (i.e., with flush_all=true). Therefore, error routes are not<br /> flushed when their nexthop object is deleted:<br /> <br /> # ip link add name dummy1 up type dummy<br /> # ip nexthop add id 1 dev dummy1<br /> # ip route add 198.51.100.1/32 nhid 1<br /> # ip route add blackhole 198.51.100.2/32 nhid 1<br /> # ip nexthop del id 1<br /> # ip route show<br /> blackhole 198.51.100.2 nhid 1 dev dummy1<br /> <br /> As such, they keep holding a reference on the nexthop object which in<br /> turn holds a reference on the nexthop device, resulting in a reference<br /> count leak:<br /> <br /> # ip link del dev dummy1<br /> [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2<br /> <br /> Fix by flushing error routes when their nexthop is marked as dead.<br /> <br /> IPv6 does not suffer from this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_gre: make ip6gre_header() robust<br /> <br /> Over the years, syzbot found many ways to crash the kernel<br /> in ip6gre_header() [1].<br /> <br /> This involves team or bonding drivers ability to dynamically<br /> change their dev-&gt;needed_headroom and/or dev-&gt;hard_header_len<br /> <br /> In this particular crash mld_newpack() allocated an skb<br /> with a too small reserve/headroom, and by the time mld_sendpack()<br /> was called, syzbot managed to attach an ip6gre device.<br /> <br /> [1]<br /> skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:213 !<br /> <br /> skb_under_panic net/core/skbuff.c:223 [inline]<br /> skb_push+0xc3/0xe0 net/core/skbuff.c:2641<br /> ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371<br /> dev_hard_header include/linux/netdevice.h:3436 [inline]<br /> neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618<br /> neigh_output include/net/neighbour.h:556 [inline]<br /> ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136<br /> __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]<br /> ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220<br /> NF_HOOK_COND include/linux/netfilter.h:307 [inline]<br /> ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247<br /> NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318<br /> mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855<br /> mld_send_cr net/ipv6/mcast.c:2154 [inline]<br /> mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fallback earlier on simult connection<br /> <br /> Syzkaller reports a simult-connect race leading to inconsistent fallback<br /> status:<br /> <br /> WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515<br /> Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6<br /> RSP: 0018:ffffc900006cf338 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf<br /> RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005<br /> RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007<br /> R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900<br /> R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004<br /> FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197<br /> tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922<br /> tcp_v6_do_rcv+0x492/0x1740 net/ipv6/tcp_ipv6.c:1672<br /> tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918<br /> ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0x1e4/0x4b0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> NF_HOOK include/linux/netfilter.h:312 [inline]<br /> ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500<br /> dst_input include/net/dst.h:471 [inline]<br /> ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> NF_HOOK include/linux/netfilter.h:312 [inline]<br /> ipv6_rcv+0x264/0x650 net/ipv6/ip6_input.c:311<br /> __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979<br /> __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092<br /> process_backlog+0x442/0x15e0 net/core/dev.c:6444<br /> __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494<br /> napi_poll net/core/dev.c:7557 [inline]<br /> net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684<br /> handle_softirqs+0x216/0x8e0 kernel/softirq.c:579<br /> run_ksoftirqd kernel/softirq.c:968 [inline]<br /> run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960<br /> smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160<br /> kthread+0x3c2/0x780 kernel/kthread.c:463<br /> ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> The TCP subflow can process the simult-connect syn-ack packet after<br /> transitioning to TCP_FIN1 state, bypassing the MPTCP fallback check,<br /> as the sk_state_change() callback is not invoked for * -&gt; FIN_WAIT1<br /> transitions.<br /> <br /> That will move the msk socket to an inconsistent status and the next<br /> incoming data will hit the reported splat.<br /> <br /> Close the race moving the simult-fallback check at the earliest possible<br /> stage - that is at syn-ack generation time.<br /> <br /> About the fixes tags: [2] was supposed to also fix this issue introduced<br /> by [3]. [1] is required as a dependence: it was not explicitly marked as<br /> a fix, but it is one and it has already been backported before [3]. In<br /> other words, this commit should be backported up to [3], including [2]<br /> and [1] if that&amp;#39;s not already there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: disable SVA when CONFIG_X86 is set<br /> <br /> Patch series "Fix stale IOTLB entries for kernel address space", v7.<br /> <br /> This proposes a fix for a security vulnerability related to IOMMU Shared<br /> Virtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel<br /> page table entries. When a kernel page table page is freed and<br /> reallocated for another purpose, the IOMMU might still hold stale,<br /> incorrect entries. This can be exploited to cause a use-after-free or<br /> write-after-free condition, potentially leading to privilege escalation or<br /> data corruption.<br /> <br /> This solution introduces a deferred freeing mechanism for kernel page<br /> table pages, which provides a safe window to notify the IOMMU to<br /> invalidate its caches before the page is reused.<br /> <br /> <br /> This patch (of 8):<br /> <br /> In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware<br /> shares and walks the CPU&amp;#39;s page tables. The x86 architecture maps the<br /> kernel&amp;#39;s virtual address space into the upper portion of every process&amp;#39;s<br /> page table. Consequently, in an SVA context, the IOMMU hardware can walk<br /> and cache kernel page table entries.<br /> <br /> The Linux kernel currently lacks a notification mechanism for kernel page<br /> table changes, specifically when page table pages are freed and reused. <br /> The IOMMU driver is only notified of changes to user virtual address<br /> mappings. This can cause the IOMMU&amp;#39;s internal caches to retain stale<br /> entries for kernel VA.<br /> <br /> Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when<br /> kernel page table pages are freed and later reallocated. The IOMMU could<br /> misinterpret the new data as valid page table entries. The IOMMU might<br /> then walk into attacker-controlled memory, leading to arbitrary physical<br /> memory DMA access or privilege escalation. This is also a<br /> Write-After-Free issue, as the IOMMU will potentially continue to write<br /> Accessed and Dirty bits to the freed memory while attempting to walk the<br /> stale page tables.<br /> <br /> Currently, SVA contexts are unprivileged and cannot access kernel<br /> mappings. However, the IOMMU will still walk kernel-only page tables all<br /> the way down to the leaf entries, where it realizes the mapping is for the<br /> kernel and errors out. This means the IOMMU still caches these<br /> intermediate page table entries, making the described vulnerability a real<br /> concern.<br /> <br /> Disable SVA on x86 architecture until the IOMMU can receive notification<br /> to flush the paging cache before freeing the CPU kernel page table pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()<br /> <br /> nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites<br /> fp-&gt;fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if<br /> the client already has a SHARE_ACCESS_READ open from a previous OPEN<br /> operation, this action overwrites the existing pointer without<br /> releasing its reference, orphaning the previous reference.<br /> <br /> Additionally, the function originally stored the same nfsd_file<br /> pointer in both fp-&gt;fi_fds[O_RDONLY] and fp-&gt;fi_rdeleg_file with<br /> only a single reference. When put_deleg_file() runs, it clears<br /> fi_rdeleg_file and calls nfs4_file_put_access() to release the file.<br /> <br /> However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when<br /> the fi_access[O_RDONLY] counter drops to zero. If another READ open<br /> exists on the file, the counter remains elevated and the nfsd_file<br /> reference from the delegation is never released. This potentially<br /> causes open conflicts on that file.<br /> <br /> Then, on server shutdown, these leaks cause __nfsd_file_cache_purge()<br /> to encounter files with an elevated reference count that cannot be<br /> cleaned up, ultimately triggering a BUG() in kmem_cache_destroy()<br /> because there are still nfsd_file objects allocated in that cache.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix OOB write in bnxt_re_copy_err_stats()<br /> <br /> Commit ef56081d1864 ("RDMA/bnxt_re: RoCE related hardware counters<br /> update") added three new counters and placed them after<br /> BNXT_RE_OUT_OF_SEQ_ERR.<br /> <br /> BNXT_RE_OUT_OF_SEQ_ERR acts as a boundary marker for allocating hardware<br /> statistics with different num_counters values on chip_gen_p5_p7 devices.<br /> <br /> As a result, BNXT_RE_NUM_STD_COUNTERS are used when allocating<br /> hw_stats, which leads to an out-of-bounds write in<br /> bnxt_re_copy_err_stats().<br /> <br /> The counters BNXT_RE_REQ_CQE_ERROR, BNXT_RE_RESP_CQE_ERROR, and<br /> BNXT_RE_RESP_REMOTE_ACCESS_ERRS are applicable to generic hardware, not<br /> only p5/p7 devices.<br /> <br /> Fix this by moving these counters before BNXT_RE_OUT_OF_SEQ_ERR so they<br /> are included in the generic counter set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cm: Fix leaking the multicast GID table reference<br /> <br /> If the CM ID is destroyed while the CM event for multicast creating is<br /> still queued the cancel_work_sync() will prevent the work from running<br /> which also prevents destroying the ah_attr. This leaks a refcount and<br /> triggers a WARN:<br /> <br /> GID entry ref leak for dev syz1 index 2 ref=573<br /> WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]<br /> WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886<br /> <br /> Destroy the ah_attr after canceling the work, it is safe to call this<br /> twice.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()<br /> <br /> There exists a kernel oops caused by a BUG_ON(nhead INT_MAX<br /> (i.e. (int)(skb_headroom(skb) + len_delta) skb_headroom(skb)) is meant to ensure<br /> that delta = headroom - skb_headroom(skb) is never negative, otherwise<br /> we will trigger a BUG_ON in pskb_expand_head(). However, if<br /> headroom &gt; INT_MAX and delta cmsg_len = cmsg_len;<br /> cmsg-&gt;cmsg_level = IPPROTO_IPV6;<br /> cmsg-&gt;cmsg_type = IPV6_HOPOPTS;<br /> char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);<br /> hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80<br /> <br /> sendmsg(fd, &amp;msg, 0);