Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent possible NULL dereference in rt6_probe()<br /> <br /> syzbot caught a NULL dereference in rt6_probe() [1]<br /> <br /> Bail out if __in6_dev_get() returns NULL.<br /> <br /> [1]<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]<br /> CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]<br /> RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758<br /> Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19<br /> RSP: 0018:ffffc900034af070 EFLAGS: 00010203<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000<br /> RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c<br /> RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a<br /> R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000<br /> FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784<br /> nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496<br /> __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825<br /> find_rr_leaf net/ipv6/route.c:853 [inline]<br /> rt6_select net/ipv6/route.c:897 [inline]<br /> fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195<br /> ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231<br /> pol_lookup_func include/net/ip6_fib.h:616 [inline]<br /> fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121<br /> ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]<br /> ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651<br /> ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147<br /> ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250<br /> rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898<br /> inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> sock_write_iter+0x4b8/0x5c0 net/socket.c:1160<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0x6b6/0x1140 fs/read_write.c:590<br /> ksys_write+0x1f8/0x260 fs/read_write.c:643<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent possible NULL deref in fib6_nh_init()<br /> <br /> syzbot reminds us that in6_dev_get() can return NULL.<br /> <br /> fib6_nh_init()<br /> ip6_validate_gw( &amp;idev )<br /> ip6_route_check_nh( idev )<br /> *idev = in6_dev_get(dev); // can be NULL<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]<br /> CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024<br /> RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606<br /> Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b<br /> RSP: 0018:ffffc900032775a0 EFLAGS: 00010202<br /> RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000<br /> RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8<br /> RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000<br /> R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8<br /> R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000<br /> FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809<br /> ip6_route_add+0x28/0x160 net/ipv6/route.c:3853<br /> ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483<br /> inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579<br /> sock_do_ioctl+0x158/0x460 net/socket.c:1222<br /> sock_ioctl+0x629/0x8e0 net/socket.c:1341<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f940f07cea9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: bmips: BCM6358: make sure CBR is correctly set<br /> <br /> It was discovered that some device have CBR address set to 0 causing<br /> kernel panic when arch_sync_dma_for_cpu_all is called.<br /> <br /> This was notice in situation where the system is booted from TP1 and<br /> BMIPS_GET_CBR() returns 0 instead of a valid address and<br /> !!(read_c0_brcm_cmt_local() &amp; (1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: add the option to have a tty reject a new ldisc<br /> <br /> ... and use it to limit the virtual terminals to just N_TTY. They are<br /> kind of special, and in particular, the "con_write()" routine violates<br /> the "writes cannot sleep" rule that some ldiscs rely on.<br /> <br /> This avoids the<br /> <br /> BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659<br /> <br /> when N_GSM has been attached to a virtual console, and gsmld_write()<br /> calls con_write() while holding a spinlock, and con_write() then tries<br /> to get the console lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: imx: Introduce timeout when waiting on transmitter empty<br /> <br /> By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential<br /> deadlock.<br /> <br /> In case of the timeout, there is not much we can do, so we simply ignore<br /> the transmitter state and optimistically try to continue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: Octeon: Add PCIe link status check<br /> <br /> The standard PCIe configuration read-write interface is used to<br /> access the configuration space of the peripheral PCIe devices<br /> of the mips processor after the PCIe link surprise down, it can<br /> generate kernel panic caused by "Data bus error". So it is<br /> necessary to add PCIe link status check for system protection.<br /> When the PCIe link is down or in training, assigning a value<br /> of 0 to the configuration address can prevent read-write behavior<br /> to the configuration space of peripheral PCIe devices, thereby<br /> preventing kernel panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Avoid hw_desc array overrun in dw-axi-dmac<br /> <br /> I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3<br /> segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()<br /> handles the hw_desc considering the descs_allocated, this scenario would result in a<br /> kernel panic (hw_desc array will be overrun).<br /> <br /> To fix this, the proposal is to add a new member to the axi_dma_desc structure,<br /> where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in<br /> axi_desc_put() to handle the hw_desc array correctly.<br /> <br /> Additionally I propose to remove the axi_chan_start_first_queued() call after completing<br /> the transfer, since it was identified that unbalance can occur (started descriptors can<br /> be interrupted and transfer ignored due to DMA channel not being enabled).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: remove clear SB_INLINECRYPT flag in default_options<br /> <br /> In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.<br /> If create new file or open file during this gap, these files<br /> will not use inlinecrypt. Worse case, it may lead to data<br /> corruption if wrappedkey_v0 is enable.<br /> <br /> Thread A: Thread B:<br /> <br /> -f2fs_remount -f2fs_file_open or f2fs_new_inode<br /> -default_options<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: do not create EA inode under buffer lock<br /> <br /> ext4_xattr_set_entry() creates new EA inodes while holding buffer lock<br /> on the external xattr block. This is problematic as it nests all the<br /> allocation locking (which acquires locks on other buffers) under the<br /> buffer lock. This can even deadlock when the filesystem is corrupted and<br /> e.g. quota file is setup to contain xattr block as data block. Move the<br /> allocation of EA inode out of ext4_xattr_set_entry() into the callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Enforce hcall result buffer validity and size<br /> <br /> plpar_hcall(), plpar_hcall9(), and related functions expect callers to<br /> provide valid result buffers of certain minimum size. Currently this<br /> is communicated only through comments in the code and the compiler has<br /> no idea.<br /> <br /> For example, if I write a bug like this:<br /> <br /> long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE<br /> plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);<br /> <br /> This compiles with no diagnostics emitted, but likely results in stack<br /> corruption at runtime when plpar_hcall9() stores results past the end<br /> of the array. (To be clear this is a contrived example and I have not<br /> found a real instance yet.)<br /> <br /> To make this class of error less likely, we can use explicitly-sized<br /> array parameters instead of pointers in the declarations for the hcall<br /> APIs. When compiled with -Warray-bounds[1], the code above now<br /> provokes a diagnostic like this:<br /> <br /> error: array argument is too small;<br /> is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]<br /> 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,<br /> | ^ ~~~~~~<br /> <br /> [1] Enabled for LLVM builds but not GCC for now. See commit<br /> 0da6e5fd6c37 ("gcc: disable &amp;#39;-Warray-bounds&amp;#39; for gcc-13 too") and<br /> related changes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: shmem: fix getting incorrect lruvec when replacing a shmem folio<br /> <br /> When testing shmem swapin, I encountered the warning below on my machine. <br /> The reason is that replacing an old shmem folio with a new one causes<br /> mem_cgroup_migrate() to clear the old folio&amp;#39;s memcg data. As a result,<br /> the old folio cannot get the correct memcg&amp;#39;s lruvec needed to remove<br /> itself from the LRU list when it is being freed. This could lead to<br /> possible serious problems, such as LRU list crashes due to holding the<br /> wrong LRU lock, and incorrect LRU statistics.<br /> <br /> To fix this issue, we can fallback to use the mem_cgroup_replace_folio()<br /> to replace the old shmem folio.<br /> <br /> [ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960<br /> [ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> [ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)<br /> [ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000<br /> [ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000<br /> [ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000<br /> [ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg &amp;&amp; !mem_cgroup_disabled())<br /> [ 5241.100338] ------------[ cut here ]------------<br /> [ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150<br /> [...]<br /> [ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150<br /> [ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150<br /> [ 5241.100376] sp : ffff80008b38b930<br /> [...]<br /> [ 5241.100398] Call trace:<br /> [ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150<br /> [ 5241.100401] __page_cache_release+0x90/0x300<br /> [ 5241.100404] __folio_put+0x50/0x108<br /> [ 5241.100406] shmem_replace_folio+0x1b4/0x240<br /> [ 5241.100409] shmem_swapin_folio+0x314/0x528<br /> [ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930<br /> [ 5241.100412] shmem_fault+0x74/0x160<br /> [ 5241.100414] __do_fault+0x40/0x218<br /> [ 5241.100417] do_shared_fault+0x34/0x1b0<br /> [ 5241.100419] do_fault+0x40/0x168<br /> [ 5241.100420] handle_pte_fault+0x80/0x228<br /> [ 5241.100422] __handle_mm_fault+0x1c4/0x440<br /> [ 5241.100424] handle_mm_fault+0x60/0x1f0<br /> [ 5241.100426] do_page_fault+0x120/0x488<br /> [ 5241.100429] do_translation_fault+0x4c/0x68<br /> [ 5241.100431] do_mem_abort+0x48/0xa0<br /> [ 5241.100434] el0_da+0x38/0xc0<br /> [ 5241.100436] el0t_64_sync_handler+0x68/0xc0<br /> [ 5241.100437] el0t_64_sync+0x14c/0x150<br /> [ 5241.100439] ---[ end trace 0000000000000000 ]---<br /> <br /> [baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: huge_memory: fix misused mapping_large_folio_support() for anon folios<br /> <br /> When I did a large folios split test, a WARNING "[ 5059.122759][ T166]<br /> Cannot split file folio to non-0 order" was triggered. But the test cases<br /> are only for anonmous folios. while mapping_large_folio_support() is only<br /> reasonable for page cache folios.<br /> <br /> In split_huge_page_to_list_to_order(), the folio passed to<br /> mapping_large_folio_support() maybe anonmous folio. The folio_test_anon()<br /> check is missing. So the split of the anonmous THP is failed. This is<br /> also the same for shmem_mapping(). We&amp;#39;d better add a check for both. But<br /> the shmem_mapping() in __split_huge_page() is not involved, as for<br /> anonmous folios, the end parameter is set to -1, so (head[i].index &gt;= end)<br /> is always false. shmem_mapping() is not called.<br /> <br /> Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon<br /> mapping, So we can detect the wrong use more easily.<br /> <br /> THP folios maybe exist in the pagecache even the file system doesn&amp;#39;t<br /> support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is<br /> enabled, khugepaged will try to collapse read-only file-backed pages to<br /> THP. But the mapping does not actually support multi order large folios<br /> properly.<br /> <br /> Using /sys/kernel/debug/split_huge_pages to verify this, with this patch,<br /> large anon THP is successfully split and the warning is ceased.