Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: Fix division by zero while replacing a resilient group<br /> <br /> The resilient nexthop group torture tests in fib_nexthop.sh exposed a<br /> possible division by zero while replacing a resilient group [1]. The<br /> division by zero occurs when the data path sees a resilient nexthop<br /> group with zero buckets.<br /> <br /> The tests replace a resilient nexthop group in a loop while traffic is<br /> forwarded through it. The tests do not specify the number of buckets<br /> while performing the replacement, resulting in the kernel allocating a<br /> stub resilient table (i.e, &amp;#39;struct nh_res_table&amp;#39;) with zero buckets.<br /> <br /> This table should never be visible to the data path, but the old nexthop<br /> group (i.e., &amp;#39;oldg&amp;#39;) might still be used by the data path when the stub<br /> table is assigned to it.<br /> <br /> Fix this by only assigning the stub table to the old nexthop group after<br /> making sure the group is no longer used by the data path.<br /> <br /> Tested with fib_nexthops.sh:<br /> <br /> Tests passed: 222<br /> Tests failed: 0<br /> <br /> [1]<br /> divide error: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 1850 Comm: ping Not tainted 5.14.0-custom-10271-ga86eb53057fe #1107<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014<br /> RIP: 0010:nexthop_select_path+0x2d2/0x1a80<br /> [...]<br /> Call Trace:<br /> fib_select_multipath+0x79b/0x1530<br /> fib_select_path+0x8fb/0x1c10<br /> ip_route_output_key_hash_rcu+0x1198/0x2da0<br /> ip_route_output_key_hash+0x190/0x340<br /> ip_route_output_flow+0x21/0x120<br /> raw_sendmsg+0x91d/0x2e10<br /> inet_sendmsg+0x9e/0xe0<br /> __sys_sendto+0x23d/0x360<br /> __x64_sys_sendto+0xe1/0x1b0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix memory leak in compat_insnlist()<br /> <br /> `compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST`<br /> ioctl (whenwhen `CONFIG_COMPAT` is enabled). It allocates memory to<br /> temporarily hold an array of `struct comedi_insn` converted from the<br /> 32-bit version in user space. This memory is only being freed if there<br /> is a fault while filling the array, otherwise it is leaked.<br /> <br /> Add a call to `kfree()` to fix the leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix page leak<br /> <br /> There&amp;#39;s a loop in afs_extend_writeback() that adds extra pages to a write<br /> we want to make to improve the efficiency of the writeback by making it<br /> larger. This loop stops, however, if we hit a page we can&amp;#39;t write back<br /> from immediately, but it doesn&amp;#39;t get rid of the page ref we speculatively<br /> acquired.<br /> <br /> This was caused by the removal of the cleanup loop when the code switched<br /> from using find_get_pages_contig() to xarray scanning as the latter only<br /> gets a single page at a time, not a batch.<br /> <br /> Fix this by putting the page on a ref on an early break from the loop.<br /> Unfortunately, we can&amp;#39;t just add that page to the pagevec we&amp;#39;re employing<br /> as we&amp;#39;ll go through that and add those pages to the RPC call.<br /> <br /> This was found by the generic/074 test. It leaks ~4GiB of RAM each time it<br /> is run - which can be observed with "top".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server<br /> <br /> AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and<br /> Linux&amp;#39;s afs client switches between them when talking to a non-YFS server<br /> if the read size, the file position or the sum of the two have the upper 32<br /> bits set of the 64-bit value.<br /> <br /> This is a problem, however, since the file position and length fields of<br /> FS.FetchData are *signed* 32-bit values.<br /> <br /> Fix this by capturing the capability bits obtained from the fileserver when<br /> it&amp;#39;s sent an FS.GetCapabilities RPC, rather than just discarding them, and<br /> then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be<br /> used to decide whether to use FS.FetchData or FS.FetchData64 - and also<br /> FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to<br /> switch on the parameter values.<br /> <br /> This capabilities flag could also be used to limit the maximum size of the<br /> file, but all servers must be checked for that.<br /> <br /> Note that the issue does not exist with FS.StoreData - that uses *unsigned*<br /> 32-bit values. It&amp;#39;s also not a problem with Auristor servers as its<br /> YFS.FetchData64 op uses unsigned 64-bit values.<br /> <br /> This can be tested by cloning a git repo through an OpenAFS client to an<br /> OpenAFS server and then doing "git status" on it from a Linux afs<br /> client[1]. Provided the clone has a pack file that&amp;#39;s in the 2G-4G range,<br /> the git status will show errors like:<br /> <br /> error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index<br /> error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index<br /> <br /> This can be observed in the server&amp;#39;s FileLog with something like the<br /> following appearing:<br /> <br /> Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001<br /> Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001<br /> Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154<br /> Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866<br /> ...<br /> Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5<br /> <br /> Note the file position of 18446744071815340032. This is the requested file<br /> position sign-extended.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: fix pages leaking when building skb in big mode<br /> <br /> We try to use build_skb() if we had sufficient tailroom. But we forget<br /> to release the unused pages chained via private in big mode which will<br /> leak pages. Fixing this by release the pages after building the skb in<br /> big mode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> enetc: Fix illegal access when reading affinity_hint<br /> <br /> irq_set_affinity_hit() stores a reference to the cpumask_t<br /> parameter in the irq descriptor, and that reference can be<br /> accessed later from irq_affinity_hint_proc_show(). Since<br /> the cpu_mask parameter passed to irq_set_affinity_hit() has<br /> only temporary storage (it&amp;#39;s on the stack memory), later<br /> accesses to it are illegal. Thus reads from the corresponding<br /> procfs affinity_hint file can result in paging request oops.<br /> <br /> The issue is fixed by the get_cpu_mask() helper, which provides<br /> a permanent storage for the cpumask_t parameter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: fix NULL deref in qeth_clear_working_pool_list()<br /> <br /> When qeth_set_online() calls qeth_clear_working_pool_list() to roll<br /> back after an error exit from qeth_hardsetup_card(), we are at risk of<br /> accessing card-&gt;qdio.in_q before it was allocated by<br /> qeth_alloc_qdio_queues() via qeth_mpc_initialize().<br /> <br /> qeth_clear_working_pool_list() then dereferences NULL, and by writing to<br /> queue-&gt;bufs[i].pool_entry scribbles all over the CPU&amp;#39;s lowcore.<br /> Resulting in a crash when those lowcore areas are used next (eg. on<br /> the next machine-check interrupt).<br /> <br /> Such a scenario would typically happen when the device is first set<br /> online and its queues aren&amp;#39;t allocated yet. An early IO error or certain<br /> misconfigs (eg. mismatched transport mode, bad portno) then cause us to<br /> error out from qeth_hardsetup_card() with card-&gt;qdio.in_q still being<br /> NULL.<br /> <br /> Fix it by checking the pointer for NULL before accessing it.<br /> <br /> Note that we also have (rare) paths inside qeth_mpc_initialize() where<br /> a configuration change can cause us to free the existing queues,<br /> expecting that subsequent code will allocate them again. If we then<br /> error out before that re-allocation happens, the same bug occurs.<br /> <br /> Root-caused-by: Heiko Carstens

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: ensure tx skbs always have the MPTCP ext<br /> <br /> Due to signed/unsigned comparison, the expression:<br /> <br /> info-&gt;size_goal - skb-&gt;len &gt; 0<br /> <br /> evaluates to true when the size goal is smaller than the<br /> skb size. That results in lack of tx cache refill, so that<br /> the skb allocated by the core TCP code lacks the required<br /> MPTCP skb extensions.<br /> <br /> Due to the above, syzbot is able to trigger the following WARN_ON():<br /> <br /> WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366<br /> Modules linked in:<br /> CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366<br /> Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9<br /> RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216<br /> RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000<br /> RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003<br /> RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280<br /> R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0<br /> FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547<br /> mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003<br /> release_sock+0xb4/0x1b0 net/core/sock.c:3206<br /> sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145<br /> mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749<br /> inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:724<br /> sock_write_iter+0x2a0/0x3e0 net/socket.c:1057<br /> call_write_iter include/linux/fs.h:2163 [inline]<br /> new_sync_write+0x40b/0x640 fs/read_write.c:507<br /> vfs_write+0x7cf/0xae0 fs/read_write.c:594<br /> ksys_write+0x1ee/0x250 fs/read_write.c:647<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x4665f9<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 bc ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9<br /> RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003<br /> RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038<br /> R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000<br /> <br /> Fix the issue rewriting the relevant expression to avoid<br /> sign-related problems - note: size_goal is always &gt;= 0.<br /> <br /> Additionally, ensure that the skb in the tx cache always carries<br /> the relevant extension.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mwifiex: bring down link before deleting interface<br /> <br /> We can deadlock when rmmod&amp;#39;ing the driver or going through firmware<br /> reset, because the cfg80211_unregister_wdev() has to bring down the link<br /> for us, ... which then grab the same wiphy lock.<br /> <br /> nl80211_del_interface() already handles a very similar case, with a nice<br /> description:<br /> <br /> /*<br /> * We hold RTNL, so this is safe, without RTNL opencount cannot<br /> * reach 0, and thus the rdev cannot be deleted.<br /> *<br /> * We need to do it for the dev_close(), since that will call<br /> * the netdev notifiers, and we need to acquire the mutex there<br /> * but don&amp;#39;t know if we get there from here or from some other<br /> * place (e.g. "ip link set ... down").<br /> */<br /> mutex_unlock(&amp;rdev-&gt;wiphy.mtx);<br /> ...<br /> <br /> Do similarly for mwifiex teardown, by ensuring we bring the link down<br /> first.<br /> <br /> Sample deadlock trace:<br /> <br /> [ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds.<br /> [ 247.110630] Not tainted 5.12.4 #5<br /> [ 247.115796] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208<br /> [ 247.133905] Call trace:<br /> [ 247.136644] __switch_to+0x130/0x170<br /> [ 247.140643] __schedule+0x714/0xa0c<br /> [ 247.144548] schedule_preempt_disabled+0x88/0xf4<br /> [ 247.149714] __mutex_lock_common+0x43c/0x750<br /> [ 247.154496] mutex_lock_nested+0x5c/0x68<br /> [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211]<br /> [ 247.165769] raw_notifier_call_chain+0x4c/0x78<br /> [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4<br /> [ 247.176305] __dev_close_many+0x7c/0x138<br /> [ 247.180693] dev_close_many+0x7c/0x10c<br /> [ 247.184893] unregister_netdevice_many+0xfc/0x654<br /> [ 247.190158] unregister_netdevice_queue+0xb4/0xe0<br /> [ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211]<br /> [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211]<br /> [ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex]<br /> [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex]<br /> [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex]<br /> [ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie]<br /> [ 247.231451] pci_device_remove+0x50/0xe0<br /> [ 247.235849] device_release_driver_internal+0x110/0x1b0<br /> [ 247.241701] driver_detach+0x5c/0x9c<br /> [ 247.245704] bus_remove_driver+0x84/0xb8<br /> [ 247.250095] driver_unregister+0x3c/0x60<br /> [ 247.254486] pci_unregister_driver+0x2c/0x90<br /> [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/mm: Fix lockup on kernel exec fault<br /> <br /> The powerpc kernel is not prepared to handle exec faults from kernel.<br /> Especially, the function is_exec_fault() will return &amp;#39;false&amp;#39; when an<br /> exec fault is taken by kernel, because the check is based on reading<br /> current-&gt;thread.regs-&gt;trap which contains the trap from user.<br /> <br /> For instance, when provoking a LKDTM EXEC_USERSPACE test,<br /> current-&gt;thread.regs-&gt;trap is set to SYSCALL trap (0xc00), and<br /> the fault taken by the kernel is not seen as an exec fault by<br /> set_access_flags_filter().<br /> <br /> Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix<br /> with autonuma") made it clear and handled it properly. But later on<br /> commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute<br /> faults") removed that handling, introducing test based on error_code.<br /> And here is the problem, because on the 603 all upper bits of SRR1<br /> get cleared when the TLB instruction miss handler bails out to ISI.<br /> <br /> Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy<br /> search_exception_tables() verification"), an exec fault from kernel<br /> at a userspace address was indirectly caught by the lack of entry for<br /> that address in the exception tables. But after that commit the<br /> kernel mainly relies on KUAP or on core mm handling to catch wrong<br /> user accesses. Here the access is not wrong, so mm handles it.<br /> It is a minor fault because PAGE_EXEC is not set,<br /> set_access_flags_filter() should set PAGE_EXEC and voila.<br /> But as is_exec_fault() returns false as explained in the beginning,<br /> set_access_flags_filter() bails out without setting PAGE_EXEC flag,<br /> which leads to a forever minor exec fault.<br /> <br /> As the kernel is not prepared to handle such exec faults, the thing to<br /> do is to fire in bad_kernel_fault() for any exec fault taken by the<br /> kernel, as it was prior to commit d3ca587404b3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix races between xattr_{set|get} and listxattr operations<br /> <br /> UBIFS may occur some problems with concurrent xattr_{set|get} and<br /> listxattr operations, such as assertion failure, memory corruption,<br /> stale xattr value[1].<br /> <br /> Fix it by importing a new rw-lock in @ubifs_inode to serilize write<br /> operations on xattr, concurrent read operations are still effective,<br /> just like ext4.<br /> <br /> [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix NULL pointer dereference in udf_symlink function<br /> <br /> In function udf_symlink, epos.bh is assigned with the value returned<br /> by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c<br /> and returns the value of sb_getblk function that could be NULL.<br /> Then, epos.bh is used without any check, causing a possible<br /> NULL pointer dereference when sb_getblk fails.<br /> <br /> This fix adds a check to validate the value of epos.bh.