Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix underflow in chain reference counter<br /> <br /> Set element addition error path decrements reference counter on chains<br /> twice: once on element release and again via nft_data_release().<br /> <br /> Then, d6b478666ffa ("netfilter: nf_tables: fix underflow in object<br /> reference counter") incorrectly fixed this by removing the stateful<br /> object reference count decrement.<br /> <br /> Restore the stateful object decrement as in b91d90368837 ("netfilter:<br /> nf_tables: fix leaking object reference count") and let<br /> nft_data_release() decrement the chain reference counter, so this is<br /> done only once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtl8xxxu: Fix memory leaks with RTL8723BU, RTL8192EU<br /> <br /> The wifi + bluetooth combo chip RTL8723BU can leak memory (especially?)<br /> when it&amp;#39;s connected to a bluetooth audio device. The busy bluetooth<br /> traffic generates lots of C2H (card to host) messages, which are not<br /> freed correctly.<br /> <br /> To fix this, move the dev_kfree_skb() call in rtl8xxxu_c2hcmd_callback()<br /> inside the loop where skb_dequeue() is called.<br /> <br /> The RTL8192EU leaks memory because the C2H messages are added to the<br /> queue and left there forever. (This was fine in the past because it<br /> probably wasn&amp;#39;t sending any C2H messages until commit e542e66b7c2e<br /> ("wifi: rtl8xxxu: gen2: Turn on the rate control"). Since that commit<br /> it sends a C2H message when the TX rate changes.)<br /> <br /> To fix this, delete the check for rf_paths &gt; 1 and the goto. Let the<br /> function process the C2H messages from RTL8192EU like the ones from<br /> the other chips.<br /> <br /> Theoretically the RTL8188FU could also leak like RTL8723BU, but it<br /> most likely doesn&amp;#39;t send C2H messages frequently enough.<br /> <br /> This change was tested with RTL8723BU by Erhard F. I tested it with<br /> RTL8188FU and RTL8192EU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: prevent NULL pointer deref during reload<br /> <br /> Calling ethtool during reload can lead to call trace, because VSI isn&amp;#39;t<br /> configured for some time, but netdev is alive.<br /> <br /> To fix it add rtnl lock for VSI deconfig and config. Set ::num_q_vectors<br /> to 0 after freeing and add a check for ::tx/rx_rings in ring related<br /> ethtool ops.<br /> <br /> Add proper unroll of filters in ice_start_eth().<br /> <br /> Reproduction:<br /> $watch -n 0.1 -d &amp;#39;ethtool -g enp24s0f0np0&amp;#39;<br /> $devlink dev reload pci/0000:18:00.0 action driver_reinit<br /> <br /> Call trace before fix:<br /> [66303.926205] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [66303.926259] #PF: supervisor read access in kernel mode<br /> [66303.926286] #PF: error_code(0x0000) - not-present page<br /> [66303.926311] PGD 0 P4D 0<br /> [66303.926332] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [66303.926358] CPU: 4 PID: 933821 Comm: ethtool Kdump: loaded Tainted: G OE 6.4.0-rc5+ #1<br /> [66303.926400] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0014.070920180847 07/09/2018<br /> [66303.926446] RIP: 0010:ice_get_ringparam+0x22/0x50 [ice]<br /> [66303.926649] Code: 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 87 c0 09 00 00 c7 46 04 e0 1f 00 00 c7 46 10 e0 1f 00 00 48 8b 50 20 8b 12 0f b7 52 3a 89 56 14 48 8b 40 28 48 8b 00 0f b7 40 58 48<br /> [66303.926722] RSP: 0018:ffffad40472f39c8 EFLAGS: 00010246<br /> [66303.926749] RAX: ffff98a8ada05828 RBX: ffff98a8c46dd060 RCX: ffffad40472f3b48<br /> [66303.926781] RDX: 0000000000000000 RSI: ffff98a8c46dd068 RDI: ffff98a8b23c4000<br /> [66303.926811] RBP: ffffad40472f3b48 R08: 00000000000337b0 R09: 0000000000000000<br /> [66303.926843] R10: 0000000000000001 R11: 0000000000000100 R12: ffff98a8b23c4000<br /> [66303.926874] R13: ffff98a8c46dd060 R14: 000000000000000f R15: ffffad40472f3a50<br /> [66303.926906] FS: 00007f6397966740(0000) GS:ffff98b390900000(0000) knlGS:0000000000000000<br /> [66303.926941] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [66303.926967] CR2: 0000000000000000 CR3: 000000011ac20002 CR4: 00000000007706e0<br /> [66303.926999] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [66303.927029] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [66303.927060] PKRU: 55555554<br /> [66303.927075] Call Trace:<br /> [66303.927094] <br /> [66303.927111] ? __die+0x23/0x70<br /> [66303.927140] ? page_fault_oops+0x171/0x4e0<br /> [66303.927176] ? exc_page_fault+0x7f/0x180<br /> [66303.927209] ? asm_exc_page_fault+0x26/0x30<br /> [66303.927244] ? ice_get_ringparam+0x22/0x50 [ice]<br /> [66303.927433] rings_prepare_data+0x62/0x80<br /> [66303.927469] ethnl_default_doit+0xe2/0x350<br /> [66303.927501] genl_family_rcv_msg_doit.isra.0+0xe3/0x140<br /> [66303.927538] genl_rcv_msg+0x1b1/0x2c0<br /> [66303.927561] ? __pfx_ethnl_default_doit+0x10/0x10<br /> [66303.927590] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [66303.927615] netlink_rcv_skb+0x58/0x110<br /> [66303.927644] genl_rcv+0x28/0x40<br /> [66303.927665] netlink_unicast+0x19e/0x290<br /> [66303.927691] netlink_sendmsg+0x254/0x4d0<br /> [66303.927717] sock_sendmsg+0x93/0xa0<br /> [66303.927743] __sys_sendto+0x126/0x170<br /> [66303.927780] __x64_sys_sendto+0x24/0x30<br /> [66303.928593] do_syscall_64+0x5d/0x90<br /> [66303.929370] ? __count_memcg_events+0x60/0xa0<br /> [66303.930146] ? count_memcg_events.constprop.0+0x1a/0x30<br /> [66303.930920] ? handle_mm_fault+0x9e/0x350<br /> [66303.931688] ? do_user_addr_fault+0x258/0x740<br /> [66303.932452] ? exc_page_fault+0x7f/0x180<br /> [66303.933193] entry_SYSCALL_64_after_hwframe+0x72/0xdc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no link<br /> <br /> hci_connect_sco currently returns NULL when there is no link (i.e. when<br /> hci_conn_link() returns NULL).<br /> <br /> sco_connect() expects an ERR_PTR in case of any error (see line 266 in<br /> sco.c). Thus, hcon set as NULL passes through to sco_conn_add(), which<br /> tries to get hcon-&gt;hdev, resulting in dereferencing a NULL pointer as<br /> reported by syzkaller.<br /> <br /> The same issue exists for iso_connect_cis() calling hci_connect_cis().<br /> <br /> Thus, make hci_connect_sco() and hci_connect_cis() return ERR_PTR<br /> instead of NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: j1939_tp_tx_dat_new(): fix out-of-bounds memory access<br /> <br /> In the j1939_tp_tx_dat_new() function, an out-of-bounds memory access<br /> could occur during the memcpy() operation if the size of skb-&gt;cb is<br /> larger than the size of struct j1939_sk_buff_cb. This is because the<br /> memcpy() operation uses the size of skb-&gt;cb, leading to a read beyond<br /> the struct j1939_sk_buff_cb.<br /> <br /> Updated the memcpy() operation to use the size of struct<br /> j1939_sk_buff_cb instead of the size of skb-&gt;cb. This ensures that the<br /> memcpy() operation only reads the memory within the bounds of struct<br /> j1939_sk_buff_cb, preventing out-of-bounds memory access.<br /> <br /> Additionally, add a BUILD_BUG_ON() to check that the size of skb-&gt;cb<br /> is greater than or equal to the size of struct j1939_sk_buff_cb. This<br /> ensures that the skb-&gt;cb buffer is large enough to hold the<br /> j1939_sk_buff_cb structure.<br /> <br /> [mkl: rephrase commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix wrong fallback logic for FDIR<br /> <br /> When adding a FDIR filter, if ice_vc_fdir_set_irq_ctx returns failure,<br /> the inserted fdir entry will not be removed and if ice_vc_fdir_write_fltr<br /> returns failure, the fdir context info for irq handler will not be cleared<br /> which may lead to inconsistent or memory leak issue. This patch refines<br /> failure cases to resolve this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: sf-pdma: pdma_desc memory leak fix<br /> <br /> Commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread support for a<br /> DMA channel") changed sf_pdma_prep_dma_memcpy() to unconditionally<br /> allocate a new sf_pdma_desc each time it is called.<br /> <br /> The driver previously recycled descs, by checking the in_use flag, only<br /> allocating additional descs if the existing one was in use. This logic<br /> was removed in commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread<br /> support for a DMA channel"), but sf_pdma_free_desc() was not changed to<br /> handle the new behaviour.<br /> <br /> As a result, each time sf_pdma_prep_dma_memcpy() is called, the previous<br /> descriptor is leaked, over time leading to memory starvation:<br /> <br /> unreferenced object 0xffffffe008447300 (size 192):<br /> comm "irq/39-mchp_dsc", pid 343, jiffies 4294906910 (age 981.200s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 ff 00 00 00 00 b8 c1 00 00 00 00 00 00 ................<br /> 00 00 70 08 10 00 00 00 00 00 00 c0 00 00 00 00 ..p.............<br /> backtrace:<br /> [] kmemleak_alloc+0x1e/0x28<br /> [] kmem_cache_alloc+0x11e/0x178<br /> [] sf_pdma_prep_dma_memcpy+0x40/0x112<br /> <br /> Add the missing kfree() to sf_pdma_free_desc(), and remove the redundant<br /> in_use flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: set goal start correctly in ext4_mb_normalize_request<br /> <br /> We need to set ac_g_ex to notify the goal start used in<br /> ext4_mb_find_by_goal. Set ac_g_ex instead of ac_f_ex in<br /> ext4_mb_normalize_request.<br /> Besides we should assure goal start is in range [first_data_block,<br /> blocks_count) as ext4_mb_initialize_context does.<br /> <br /> [ Added a check to make sure size is less than ar-&gt;pright; otherwise<br /> we could end up passing an underflowed value of ar-&gt;pright - size to<br /> ext4_get_group_no_and_offset(), which will trigger a BUG_ON later on.<br /> - TYT ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix potential memory leaks at error path for UMP open<br /> <br /> The allocation and initialization errors at alloc_midi_urbs() that is<br /> called at MIDI 2.0 / UMP device are supposed to be handled at the<br /> caller side by invoking free_midi_urbs(). However, free_midi_urbs()<br /> loops only for ep-&gt;num_urbs entries, and since ep-&gt;num_entries wasn&amp;#39;t<br /> updated yet at the allocation / init error in alloc_midi_urbs(), this<br /> entry won&amp;#39;t be released.<br /> <br /> The intention of free_midi_urbs() is to release the whole elements, so<br /> change the loop size to NUM_URBS to scan over all elements for fixing<br /> the missed releases.<br /> <br /> Also, the call of free_midi_urbs() is missing at<br /> snd_usb_midi_v2_open(). Although it&amp;#39;ll be released later at<br /> reopen/close or disconnection, it&amp;#39;s better to release immediately at<br /> the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between balance and cancel/pause<br /> <br /> Syzbot reported a panic that looks like this:<br /> <br /> assertion failed: fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/messages.c:259!<br /> RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259<br /> Call Trace:<br /> <br /> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline]<br /> btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline]<br /> btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The reproducer is running a balance and a cancel or pause in parallel.<br /> The way balance finishes is a bit wonky, if we were paused we need to<br /> save the balance_ctl in the fs_info, but clear it otherwise and cleanup.<br /> However we rely on the return values being specific errors, or having a<br /> cancel request or no pause request. If balance completes and returns 0,<br /> but we have a pause or cancel request we won&amp;#39;t do the appropriate<br /> cleanup, and then the next time we try to start a balance we&amp;#39;ll trip<br /> this ASSERT.<br /> <br /> The error handling is just wrong here, we always want to clean up,<br /> unless we got -ECANCELLED and we set the appropriate pause flag in the<br /> exclusive op. With this patch the reproducer ran for an hour without<br /> tripping, previously it would trip in less than a few minutes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Destroy target device if coalesced MMIO unregistration fails<br /> <br /> Destroy and free the target coalesced MMIO device if unregistering said<br /> device fails. As clearly noted in the code, kvm_io_bus_unregister_dev()<br /> does not destroy the target device.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888112a54880 (size 64):<br /> comm "syz-executor.2", pid 5258, jiffies 4297861402 (age 14.129s)<br /> hex dump (first 32 bytes):<br /> 38 c7 67 15 00 c9 ff ff 38 c7 67 15 00 c9 ff ff 8.g.....8.g.....<br /> e0 c7 e1 83 ff ff ff ff 00 30 67 15 00 c9 ff ff .........0g.....<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:556 [inline]<br /> [] kzalloc include/linux/slab.h:690 [inline]<br /> [] kvm_vm_ioctl_register_coalesced_mmio+0x8e/0x3d0 arch/x86/kvm/../../../virt/kvm/coalesced_mmio.c:150<br /> [] kvm_vm_ioctl+0x47d/0x1600 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3323<br /> [] vfs_ioctl fs/ioctl.c:46 [inline]<br /> [] file_ioctl fs/ioctl.c:509 [inline]<br /> [] do_vfs_ioctl+0xbab/0x1160 fs/ioctl.c:696<br /> [] ksys_ioctl+0x76/0xa0 fs/ioctl.c:713<br /> [] __do_sys_ioctl fs/ioctl.c:720 [inline]<br /> [] __se_sys_ioctl fs/ioctl.c:718 [inline]<br /> [] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718<br /> [] do_syscall_64+0x9f/0x4e0 arch/x86/entry/common.c:290<br /> [] entry_SYSCALL_64_after_hwframe+0x49/0xbe<br /> <br /> BUG: leak checking failed

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rsi: Do not configure WoWlan in shutdown hook if not enabled<br /> <br /> In case WoWlan was never configured during the operation of the system,<br /> the hw-&gt;wiphy-&gt;wowlan_config will be NULL. rsi_config_wowlan() checks<br /> whether wowlan_config is non-NULL and if it is not, then WARNs about it.<br /> The warning is valid, as during normal operation the rsi_config_wowlan()<br /> should only ever be called with non-NULL wowlan_config. In shutdown this<br /> rsi_config_wowlan() should only ever be called if WoWlan was configured<br /> before by the user.<br /> <br /> Add checks for non-NULL wowlan_config into the shutdown hook. While at it,<br /> check whether the wiphy is also non-NULL before accessing wowlan_config .<br /> Drop the single-use wowlan_config variable, just inline it into function<br /> call.