Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix deadlock in AP/VLAN handling<br /> <br /> Syzbot reports that when you have AP_VLAN interfaces that are up<br /> and close the AP interface they belong to, we get a deadlock. No<br /> surprise - since we dev_close() them with the wiphy mutex held,<br /> which goes back into the netdev notifier in cfg80211 and tries to<br /> acquire the wiphy mutex there.<br /> <br /> To fix this, we need to do two things:<br /> 1) prevent changing iftype while AP_VLANs are up, we can&amp;#39;t<br /> easily fix this case since cfg80211 already calls us with<br /> the wiphy mutex held, but change_interface() is relatively<br /> rare in drivers anyway, so changing iftype isn&amp;#39;t used much<br /> (and userspace has to fall back to down/change/up anyway)<br /> 2) pull the dev_close() loop over VLANs out of the wiphy mutex<br /> section in the normal stop case

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer<br /> <br /> Both Intel and AMD consider it to be architecturally valid for XRSTOR to<br /> fail with #PF but nonetheless change the register state. The actual<br /> conditions under which this might occur are unclear [1], but it seems<br /> plausible that this might be triggered if one sibling thread unmaps a page<br /> and invalidates the shared TLB while another sibling thread is executing<br /> XRSTOR on the page in question.<br /> <br /> __fpu__restore_sig() can execute XRSTOR while the hardware registers<br /> are preserved on behalf of a different victim task (using the<br /> fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but<br /> modify the registers.<br /> <br /> If this happens, then there is a window in which __fpu__restore_sig()<br /> could schedule out and the victim task could schedule back in without<br /> reloading its own FPU registers. This would result in part of the FPU<br /> state that __fpu__restore_sig() was attempting to load leaking into the<br /> victim task&amp;#39;s user-visible state.<br /> <br /> Invalidate preserved FPU registers on XRSTOR failure to prevent this<br /> situation from corrupting any state.<br /> <br /> [1] Frequent readers of the errata lists might imagine "complex<br /> microarchitectural conditions".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Prevent state corruption in __fpu__restore_sig()<br /> <br /> The non-compacted slowpath uses __copy_from_user() and copies the entire<br /> user buffer into the kernel buffer, verbatim. This means that the kernel<br /> buffer may now contain entirely invalid state on which XRSTOR will #GP.<br /> validate_user_xstate_header() can detect some of that corruption, but that<br /> leaves the onus on callers to clear the buffer.<br /> <br /> Prior to XSAVES support, it was possible just to reinitialize the buffer,<br /> completely, but with supervisor states that is not longer possible as the<br /> buffer clearing code split got it backwards. Fixing that is possible but<br /> not corrupting the state in the first place is more robust.<br /> <br /> Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate()<br /> which validates the XSAVE header contents before copying the actual states<br /> to the kernel. copy_user_to_xstate() was previously only called for<br /> compacted-format kernel buffers, but it works for both compacted and<br /> non-compacted forms.<br /> <br /> Using it for the non-compacted form is slower because of multiple<br /> __copy_from_user() operations, but that cost is less important than robust<br /> code in an already slow path.<br /> <br /> [ Changelog polished by Dave Hansen ]

Umbraco CMS is an ASP.NET CMS used by more than 730.000 websites. Stored Cross-site scripting (XSS) enable attackers that have access to backoffice to bring malicious content into a website or application. This vulnerability has been patched in version(s) 8.18.13, 10.8.4, 12.3.7, 13.1.1 by implementing IHtmlSanitizer.<br /> <br /> <br /> <br /> <br />