Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: fix Use-after-Free, hold skb ref while in use<br /> <br /> This patch fixes a Use-after-Free found by the syzbot.<br /> <br /> The problem is that a skb is taken from the per-session skb queue,<br /> without incrementing the ref count. This leads to a Use-after-Free if<br /> the skb is taken concurrently from the session queue due to a CTS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: rt4801: Fix NULL pointer dereference if priv-&gt;enable_gpios is NULL<br /> <br /> devm_gpiod_get_array_optional may return NULL if no GPIO was assigned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()<br /> <br /> Use clk_disable_unprepare() in the error path of mtk_phy_init() to fix<br /> some resource leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: fix potential use-after-free in ec_bhf_remove<br /> <br /> static void ec_bhf_remove(struct pci_dev *dev)<br /> {<br /> ...<br /> struct ec_bhf_priv *priv = netdev_priv(net_dev);<br /> <br /> unregister_netdev(net_dev);<br /> free_netdev(net_dev);<br /> <br /> pci_iounmap(dev, priv-&gt;dma_io);<br /> pci_iounmap(dev, priv-&gt;io);<br /> ...<br /> }<br /> <br /> priv is netdev private data, but it is used<br /> after free_netdev(). It can cause use-after-free when accessing priv<br /> pointer. So, fix it by moving free_netdev() after pci_iounmap()<br /> calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cdc_eem: fix tx fixup skb leak<br /> <br /> when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),<br /> if skb_copy_expand() failed, it return NULL,<br /> usbnet_start_xmit() will have no chance to free original skb.<br /> <br /> fix it by free orginal skb in eem_tx_fixup() first,<br /> then check skb clone status, if failed, return NULL to usbnet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hamradio: fix memory leak in mkiss_close<br /> <br /> My local syzbot instance hit memory leak in<br /> mkiss_open()[1]. The problem was in missing<br /> free_netdev() in mkiss_close().<br /> <br /> In mkiss_open() netdevice is allocated and then<br /> registered, but in mkiss_close() netdevice was<br /> only unregistered, but not freed.<br /> <br /> Fail log:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880281ba000 (size 4096):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0.............<br /> 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .&amp;#39;.*............<br /> backtrace:<br /> [] kvmalloc_node+0x61/0xf0<br /> [] alloc_netdev_mqs+0x98/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880141a9a00 (size 96):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(....<br /> 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@..........<br /> backtrace:<br /> [] __hw_addr_create_ex+0x5b/0x310<br /> [] __hw_addr_add_ex+0x1f8/0x2b0<br /> [] dev_addr_init+0x10b/0x1f0<br /> [] alloc_netdev_mqs+0x13b/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880219bfc00 (size 512):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............<br /> 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kvmalloc_node+0x61/0xf0<br /> [] alloc_netdev_mqs+0x777/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888029b2b200 (size 256):<br /> comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kvmalloc_node+0x61/0xf0<br /> [] alloc_netdev_mqs+0x912/0xe80<br /> [] mkiss_open+0xb2/0x6f0 [1]<br /> [] tty_ldisc_open+0x9b/0x110<br /> [] tty_set_ldisc+0x2e8/0x670<br /> [] tty_ioctl+0xda3/0x1440<br /> [] __x64_sys_ioctl+0x193/0x200<br /> [] do_syscall_64+0x3a/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: avoid a use-after-free when BO init fails<br /> <br /> nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code<br /> back to the caller. On failures, ttm_bo_init() invokes the provided<br /> destructor which should de-initialize and free the memory.<br /> <br /> Thus, when nouveau_bo_init() returns an error the gem object has already<br /> been released and the memory freed by nouveau_bo_del_ttm().

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: actually fix freelist pointer vs redzoning<br /> <br /> It turns out that SLUB redzoning ("slub_debug=Z") checks from<br /> s-&gt;object_size rather than from s-&gt;inuse (which is normally bumped to<br /> make room for the freelist pointer), so a cache created with an object<br /> size less than 24 would have the freelist pointer written beyond<br /> s-&gt;object_size, causing the redzone to be corrupted by the freelist<br /> pointer. This was very visible with "slub_debug=ZF":<br /> <br /> BUG test (Tainted: G B ): Right Redzone overwritten<br /> -----------------------------------------------------------------------------<br /> <br /> INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb<br /> INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200<br /> INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620<br /> <br /> Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........<br /> Object (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........<br /> Redzone (____ptrval____): 40 1d e8 1a aa @....<br /> Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........<br /> <br /> Adjust the offset to stay within s-&gt;object_size.<br /> <br /> (Note that no caches of in this size range are known to exist in the<br /> kernel currently.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: fix vlan tunnel dst refcnt when egressing<br /> <br /> The egress tunnel code uses dst_clone() and directly sets the result<br /> which is wrong because the entry might have 0 refcnt or be already deleted,<br /> causing number of problems. It also triggers the WARN_ON() in dst_hold()[1]<br /> when a refcnt couldn&amp;#39;t be taken. Fix it by using dst_hold_safe() and<br /> checking if a reference was actually taken before setting the dst.<br /> <br /> [1] dmesg WARN_ON log and following refcnt errors<br /> WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]<br /> Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net<br /> CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014<br /> RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]<br /> Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49<br /> RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0<br /> RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001<br /> R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000<br /> R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401<br /> FS: 0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0<br /> Call Trace:<br /> br_handle_vlan+0xbc/0xca [bridge]<br /> __br_forward+0x23/0x164 [bridge]<br /> deliver_clone+0x41/0x48 [bridge]<br /> br_handle_frame_finish+0x36f/0x3aa [bridge]<br /> ? skb_dst+0x2e/0x38 [bridge]<br /> ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge]<br /> ? br_handle_frame_finish+0x3aa/0x3aa [bridge]<br /> br_handle_frame+0x2c3/0x377 [bridge]<br /> ? __skb_pull+0x33/0x51<br /> ? vlan_do_receive+0x4f/0x36a<br /> ? br_handle_frame_finish+0x3aa/0x3aa [bridge]<br /> __netif_receive_skb_core+0x539/0x7c6<br /> ? __list_del_entry_valid+0x16e/0x1c2<br /> __netif_receive_skb_list_core+0x6d/0xd6<br /> netif_receive_skb_list_internal+0x1d9/0x1fa<br /> gro_normal_list+0x22/0x3e<br /> dev_gro_receive+0x55b/0x600<br /> ? detach_buf_split+0x58/0x140<br /> napi_gro_receive+0x94/0x12e<br /> virtnet_poll+0x15d/0x315 [virtio_net]<br /> __napi_poll+0x2c/0x1c9<br /> net_rx_action+0xe6/0x1fb<br /> __do_softirq+0x115/0x2d8<br /> run_ksoftirqd+0x18/0x20<br /> smpboot_thread_fn+0x183/0x19c<br /> ? smpboot_unregister_percpu_thread+0x66/0x66<br /> kthread+0x10a/0x10f<br /> ? kthread_mod_delayed_work+0xb6/0xb6<br /> ret_from_fork+0x22/0x30<br /> ---[ end trace 49f61b07f775fd2b ]---<br /> dst_release: dst:00000000c02d677a refcnt:-1<br /> dst_release underflow

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: fix vlan tunnel dst null pointer dereference<br /> <br /> This patch fixes a tunnel_dst null pointer dereference due to lockless<br /> access in the tunnel egress path. When deleting a vlan tunnel the<br /> tunnel_dst pointer is set to NULL without waiting a grace period (i.e.<br /> while it&amp;#39;s still usable) and packets egressing are dereferencing it<br /> without checking. Use READ/WRITE_ONCE to annotate the lockless use of<br /> tunnel_id, use RCU for accessing tunnel_dst and make sure it is read<br /> only once and checked in the egress path. The dst is already properly RCU<br /> protected so we don&amp;#39;t need to do anything fancy than to make sure<br /> tunnel_id and tunnel_dst are read only once and checked in the egress path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ll_temac: Make sure to free skb when it is completely used<br /> <br /> With the skb pointer piggy-backed on the TX BD, we have a simple and<br /> efficient way to free the skb buffer when the frame has been transmitted.<br /> But in order to avoid freeing the skb while there are still fragments from<br /> the skb in use, we need to piggy-back on the TX BD of the skb, not the<br /> first.<br /> <br /> Without this, we are doing use-after-free on the DMA side, when the first<br /> BD of a multi TX BD packet is seen as completed in xmit_done, and the<br /> remaining BDs are still being processed.