Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: add accessors to read/set tp-&gt;snd_cwnd<br /> <br /> We had various bugs over the years with code<br /> breaking the assumption that tp-&gt;snd_cwnd is greater<br /> than zero.<br /> <br /> Lately, syzbot reported the WARN_ON_ONCE(!tp-&gt;prior_cwnd) added<br /> in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")<br /> can trigger, and without a repro we would have to spend<br /> considerable time finding the bug.<br /> <br /> Instead of complaining too late, we want to catch where<br /> and when tp-&gt;snd_cwnd is set to an illegal value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtl818x: Prevent using not initialized queues<br /> <br /> Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.<br /> Ignore the skb priority for those cards, they only have one tx queue. Pierre<br /> Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:<br /> <br /> https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html<br /> <br /> He also confirmed that this patch fixes the issue. In summary this happened:<br /> <br /> After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a<br /> "divide error: 0000" when connecting to an AP. Control port tx now tries to<br /> use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in<br /> 2.10.<br /> <br /> Since only the rtl8187se part of the driver supports QoS, the priority<br /> of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185<br /> cards.<br /> <br /> rtl8180 is then unconditionally reading out the priority and finally crashes on<br /> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this<br /> patch:<br /> idx = (ring-&gt;idx + skb_queue_len(&amp;ring-&gt;queue)) % ring-&gt;entries<br /> <br /> "ring-&gt;entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: avoid journal no-space deadlock by reserving 1 journal bucket<br /> <br /> The journal no-space deadlock was reported time to time. Such deadlock<br /> can happen in the following situation.<br /> <br /> When all journal buckets are fully filled by active jset with heavy<br /> write I/O load, the cache set registration (after a reboot) will load<br /> all active jsets and inserting them into the btree again (which is<br /> called journal replay). If a journaled bkey is inserted into a btree<br /> node and results btree node split, new journal request might be<br /> triggered. For example, the btree grows one more level after the node<br /> split, then the root node record in cache device super block will be<br /> upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no<br /> space in journal buckets, the journal replay has to wait for new journal<br /> bucket to be reclaimed after at least one journal bucket replayed. This<br /> is one example that how the journal no-space deadlock happens.<br /> <br /> The solution to avoid the deadlock is to reserve 1 journal bucket in<br /> run time, and only permit the reserved journal bucket to be used during<br /> cache set registration procedure for things like journal replay. Then<br /> the journal space will never be fully filled, there is no chance for<br /> journal no-space deadlock to happen anymore.<br /> <br /> This patch adds a new member "bool do_reserve" in struct journal, it is<br /> inititalized to 0 (false) when struct journal is allocated, and set to<br /> 1 (true) by bch_journal_space_reserve() when all initialization done in<br /> run_cache_set(). In the run time when journal_reclaim() tries to<br /> allocate a new journal bucket, free_journal_buckets() is called to check<br /> whether there are enough free journal buckets to use. If there is only<br /> 1 free journal bucket and journal-&gt;do_reserve is 1 (true), the last<br /> bucket is reserved and free_journal_buckets() will return 0 to indicate<br /> no free journal bucket. Then journal_reclaim() will give up, and try<br /> next time to see whetheer there is free journal bucket to allocate. By<br /> this method, there is always 1 jouranl bucket reserved in run time.<br /> <br /> During the cache set registration, journal-&gt;do_reserve is 0 (false), so<br /> the reserved journal bucket can be used to avoid the no-space deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: fix use-after-free by removing a non-RCU wcid pointer<br /> <br /> Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule<br /> by protecting mtxq-&gt;wcid with rcu_lock between mt76_txq_schedule and<br /> sta_info_[alloc, free].<br /> <br /> [18853.876689] ==================================================================<br /> [18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76]<br /> [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883<br /> [18853.876786]<br /> [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215<br /> <br /> [18853.876840] Call trace:<br /> [18853.876861] dump_backtrace+0x0/0x3ec<br /> [18853.876878] show_stack+0x20/0x2c<br /> [18853.876899] dump_stack+0x11c/0x1ac<br /> [18853.876918] print_address_description+0x74/0x514<br /> [18853.876934] kasan_report+0x134/0x174<br /> [18853.876948] __asan_report_load8_noabort+0x44/0x50<br /> [18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047]<br /> [18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877071] kthread+0x2f8/0x3b8<br /> [18853.877087] ret_from_fork+0x10/0x30<br /> [18853.877098]<br /> [18853.877112] Allocated by task 941:<br /> [18853.877131] kasan_save_stack+0x38/0x68<br /> [18853.877147] __kasan_kmalloc+0xd4/0xfc<br /> [18853.877163] kasan_kmalloc+0x10/0x1c<br /> [18853.877177] __kmalloc+0x264/0x3c4<br /> [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211]<br /> [18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211]<br /> [18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211]<br /> [18853.877635] ieee80211_auth+0x20/0x2c [mac80211]<br /> [18853.877733] rdev_auth+0x7c/0x438 [cfg80211]<br /> [18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211]<br /> [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211]<br /> [18853.877938] genl_rcv_msg+0x748/0x93c<br /> [18853.877954] netlink_rcv_skb+0x160/0x2a8<br /> [18853.877969] genl_rcv+0x3c/0x54<br /> [18853.877985] netlink_unicast_kernel+0x104/0x1ec<br /> [18853.877999] netlink_unicast+0x178/0x268<br /> [18853.878015] netlink_sendmsg+0x3cc/0x5f0<br /> [18853.878030] sock_sendmsg+0xb4/0xd8<br /> [18853.878043] ____sys_sendmsg+0x2f8/0x53c<br /> [18853.878058] ___sys_sendmsg+0xe8/0x150<br /> [18853.878071] __sys_sendmsg+0xc4/0x1f4<br /> [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c<br /> [18853.878101] el0_svc_common+0x1b4/0x390<br /> [18853.878115] do_el0_svc_compat+0x8c/0xdc<br /> [18853.878131] el0_svc_compat+0x10/0x1c<br /> [18853.878146] el0_sync_compat_handler+0xa8/0xcc<br /> [18853.878161] el0_sync_compat+0x188/0x1c0<br /> [18853.878171]<br /> [18853.878183] Freed by task 10927:<br /> [18853.878200] kasan_save_stack+0x38/0x68<br /> [18853.878215] kasan_set_track+0x28/0x3c<br /> [18853.878228] kasan_set_free_info+0x24/0x48<br /> [18853.878244] __kasan_slab_free+0x11c/0x154<br /> [18853.878259] kasan_slab_free+0x14/0x24<br /> [18853.878273] slab_free_freelist_hook+0xac/0x1b0<br /> [18853.878287] kfree+0x104/0x390<br /> [18853.878402] sta_info_free+0x198/0x210 [mac80211]<br /> [18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211]<br /> [18853.878628] __sta_info_flush+0x300/0x37c [mac80211]<br /> [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211]<br /> [18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211]<br /> [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211]<br /> [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211]<br /> [18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211]<br /> [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211]<br /> [18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211]<br /> [18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211]<br /> [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211]<br /> [18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211]<br /> [18853.879628] dpm_run_callback+0x58/0x408<br /> [18853.879642] __device_suspend+0x4cc/0x864<br /> [18853.879658] async_suspend+0x34/0xf4<br /> [18<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: Fix NULL pointer dereference on sysfs access<br /> <br /> The control device has no drvdata. So we will get a<br /> NULL pointer dereference when accessing control<br /> device&amp;#39;s msg_timeout attribute via sysfs:<br /> <br /> [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8<br /> [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)<br /> [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)<br /> [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)<br /> [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)<br /> [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)<br /> [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)<br /> [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)<br /> [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)<br /> [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))<br /> [ 132.876319][ T3644] kernel_read (fs/read_write.c:459)<br /> [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)<br /> [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)<br /> [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)<br /> [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)<br /> [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)<br /> [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)<br /> <br /> To fix it, don&amp;#39;t create the unneeded attribute for<br /> control device anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd<br /> <br /> syzbot got a new report [1] finally pointing to a very old bug,<br /> added in initial support for MTU probing.<br /> <br /> tcp_mtu_probe() has checks about starting an MTU probe if<br /> tcp_snd_cwnd(tp) &gt;= 11.<br /> <br /> But nothing prevents tcp_snd_cwnd(tp) to be reduced later<br /> and before the MTU probe succeeds.<br /> <br /> This bug would lead to potential zero-divides.<br /> <br /> Debugging added in commit 40570375356c ("tcp: add accessors<br /> to read/set tp-&gt;snd_cwnd") has paid off :)<br /> <br /> While we are at it, address potential overflows in this code.<br /> <br /> [1]<br /> WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712<br /> Modules linked in:<br /> CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]<br /> RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712<br /> Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff<br /> RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287<br /> RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000<br /> RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f<br /> RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520<br /> R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50<br /> R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000<br /> FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356<br /> tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861<br /> tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973<br /> tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476<br /> sk_backlog_rcv include/net/sock.h:1061 [inline]<br /> __release_sock+0x1d8/0x4c0 net/core/sock.c:2849<br /> release_sock+0x5d/0x1c0 net/core/sock.c:3404<br /> sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145<br /> tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410<br /> tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> __sys_sendto+0x439/0x5c0 net/socket.c:2119<br /> __do_sys_sendto net/socket.c:2131 [inline]<br /> __se_sys_sendto net/socket.c:2127 [inline]<br /> __x64_sys_sendto+0xda/0xf0 net/socket.c:2127<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f6431289109<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109<br /> RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a<br /> RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling<br /> <br /> Error paths do not free previously allocated memory. Add devm_kfree() to<br /> those failure paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Address NULL pointer dereference after starget_to_rport()<br /> <br /> Calls to starget_to_rport() may return NULL. Add check for NULL rport<br /> before dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: usb: host: Fix deadlock in oxu_bus_suspend()<br /> <br /> There is a deadlock in oxu_bus_suspend(), which is shown below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | timer_action()<br /> oxu_bus_suspend() | mod_timer()<br /> spin_lock_irq() //(1) | (wait a time)<br /> ... | oxu_watchdog()<br /> del_timer_sync() | spin_lock_irq() //(2)<br /> (wait timer to stop) | ...<br /> <br /> We hold oxu-&gt;lock in position (1) of thread 1, and use<br /> del_timer_sync() to wait timer to stop, but timer handler<br /> also need oxu-&gt;lock in position (2) of thread 2. As a result,<br /> oxu_bus_suspend() will block forever.<br /> <br /> This patch extracts del_timer_sync() from the protection of<br /> spin_lock_irq(), which could let timer handler to obtain<br /> the needed lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: Fix a possible resource leak in icom_probe<br /> <br /> When pci_read_config_dword failed, call pci_release_regions() and<br /> pci_disable_device() to recycle the resource previously allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()<br /> <br /> There is a deadlock in rtllib_beacons_stop(), which is shown<br /> below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | rtllib_send_beacon()<br /> rtllib_beacons_stop() | mod_timer()<br /> spin_lock_irqsave() //(1) | (wait a time)<br /> ... | rtllib_send_beacon_cb()<br /> del_timer_sync() | spin_lock_irqsave() //(2)<br /> (wait timer to stop) | ...<br /> <br /> We hold ieee-&gt;beacon_lock in position (1) of thread 1 and<br /> use del_timer_sync() to wait timer to stop, but timer handler<br /> also need ieee-&gt;beacon_lock in position (2) of thread 2.<br /> As a result, rtllib_beacons_stop() will block forever.<br /> <br /> This patch extracts del_timer_sync() from the protection of<br /> spin_lock_irqsave(), which could let timer handler to obtain<br /> the needed lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls<br /> <br /> When doing layoutget as part of the open() compound, we have to be<br /> careful to release the layout locks before we can call any further RPC<br /> calls, such as setattr(). The reason is that those calls could trigger<br /> a recall, which could deadlock.