Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX<br /> <br /> Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()<br /> when resizing hashtable because __GFP_NOWARN is unset.<br /> <br /> Similar to:<br /> <br /> b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()<br /> <br /> bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf<br /> program. When BPF JIT is disabled or under 32-bit host,<br /> bpf_map_lookup_percpu_elem() will not be inlined. Using it in a<br /> sleepable bpf program will trigger the warning in<br /> bpf_map_lookup_percpu_elem(), because the bpf program only holds<br /> rcu_read_lock_trace lock. Therefore, add the missed check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Fix null-ptr-deref in jfs_ioc_trim<br /> <br /> [ Syzkaller Report ]<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000087: 0000 [#1<br /> KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]<br /> CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted<br /> 6.13.0-rc6-gfbfd64d25c7a-dirty #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Sched_ext: serialise (enabled+all), task: runnable_at=-30ms<br /> RIP: 0010:jfs_ioc_trim+0x34b/0x8f0<br /> Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93<br /> 90 82 fe ff 4c 89 ff 31 f6<br /> RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206<br /> RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a<br /> RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001<br /> RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000<br /> R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438<br /> FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die_body+0x61/0xb0<br /> ? die_addr+0xb1/0xe0<br /> ? exc_general_protection+0x333/0x510<br /> ? asm_exc_general_protection+0x26/0x30<br /> ? jfs_ioc_trim+0x34b/0x8f0<br /> jfs_ioctl+0x3c8/0x4f0<br /> ? __pfx_jfs_ioctl+0x10/0x10<br /> ? __pfx_jfs_ioctl+0x10/0x10<br /> __se_sys_ioctl+0x269/0x350<br /> ? __pfx___se_sys_ioctl+0x10/0x10<br /> ? do_syscall_64+0xfb/0x210<br /> do_syscall_64+0xee/0x210<br /> ? syscall_exit_to_user_mode+0x1e0/0x330<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe51f4903ad<br /> Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48<br /> 89 f7 48 89 d6 48 89 ca 4d<br /> RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad<br /> RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640<br /> R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:jfs_ioc_trim+0x34b/0x8f0<br /> Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93<br /> 90 82 fe ff 4c 89 ff 31 f6<br /> RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206<br /> RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a<br /> RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001<br /> RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000<br /> R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438<br /> FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> [ Analysis ]<br /> <br /> We believe that we have found a concurrency bug in the `fs/jfs` module<br /> that results in a null pointer dereference. There is a closely related<br /> issue which has been fixed:<br /> <br /> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234<br /> <br /> ... but, unfortunately, the accepted patch appears to still be<br /> susceptible to a null pointer dereference under some interleavings.<br /> <br /> To trigger the bug, we think that `JFS_SBI(ipbmap-&gt;i_sb)-&gt;bmap` is set<br /> to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This<br /> bug manifests quite rarely under normal circumstances, but is<br /> triggereable from a syz-program.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds read in add_missing_indices<br /> <br /> stbl is s8 but it must contain offsets into slot which can go from 0 to<br /> 127.<br /> <br /> Added a bound check for that error and return -EIO if the check fails.<br /> Also make jfs_readdir return with error if add_missing_indices returns<br /> with an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1<br /> <br /> [Why]<br /> If the dummy values in `populate_dummy_dml_surface_cfg()` aren&amp;#39;t updated<br /> then they can lead to a divide by zero in downstream callers like<br /> CalculateVMAndRowBytes()<br /> <br /> [How]<br /> Initialize dummy value to a value to avoid divide by zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix double free in delayed_free<br /> <br /> The double free could happen in the following path.<br /> <br /> exfat_create_upcase_table()<br /> exfat_create_upcase_table() : return error<br /> exfat_free_upcase_table() : free -&gt;vol_utbl<br /> exfat_load_default_upcase_table : return error<br /> exfat_kill_sb()<br /> delayed_free()<br /> exfat_free_upcase_table() vol_util as NULL after freeing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix uprobe pte be overwritten when expanding vma<br /> <br /> Patch series "Fix uprobe pte be overwritten when expanding vma".<br /> <br /> <br /> This patch (of 4):<br /> <br /> We encountered a BUG alert triggered by Syzkaller as follows:<br /> BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1<br /> <br /> And we can reproduce it with the following steps:<br /> 1. register uprobe on file at zero offset<br /> 2. mmap the file at zero offset:<br /> addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);<br /> 3. mremap part of vma1 to new vma2:<br /> addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);<br /> 4. mremap back to orig addr1:<br /> mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);<br /> <br /> In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2<br /> with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1<br /> to vma2, then unmap the vma1 range [addr1, addr1 + 4096].<br /> <br /> In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the<br /> addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096,<br /> addr1 + 8192] still maps the file, it will take vma_merge_new_range to<br /> expand the range, and then do uprobe_mmap in vma_complete. Since the<br /> merged vma pgoff is also zero offset, it will install uprobe anon page to<br /> the merged vma. However, the upcomming move_page_tables step, which use<br /> set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite<br /> the newly uprobe pte in the merged vma, and lead that pte to be orphan.<br /> <br /> Since the uprobe pte will be remapped to the merged vma, we can remove the<br /> unnecessary uprobe_mmap upon merged vma.<br /> <br /> This problem was first found in linux-6.6.y and also exists in the<br /> community syzkaller:<br /> https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: add NULL check in automount_fullpath<br /> <br /> page is checked for null in __build_path_from_dentry_optional_prefix<br /> when tcon-&gt;origin_fullpath is not set. However, the check is missing when<br /> it is set.<br /> Add a check to prevent a potential NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: Make sure modelist not set on unregistered console<br /> <br /> It looks like attempting to write to the "store_modes" sysfs node will<br /> run afoul of unregistered consoles:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28<br /> index -1 is out of range for type &amp;#39;fb_info *[32]&amp;#39;<br /> ...<br /> fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122<br /> fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048<br /> fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673<br /> store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113<br /> dev_attr_store+0x55/0x80 drivers/base/core.c:2439<br /> <br /> static struct fb_info *fbcon_registered_fb[FB_MAX];<br /> ...<br /> static signed char con2fb_map[MAX_NR_CONSOLES];<br /> ...<br /> static struct fb_info *fbcon_info_from_console(int console)<br /> ...<br /> return fbcon_registered_fb[con2fb_map[console]];<br /> <br /> If con2fb_map contains a -1 things go wrong here. Instead, return NULL,<br /> as callers of fbcon_info_from_console() are trying to compare against<br /> existing "info" pointers, so error handling should kick in correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix memory leak due to multiple rx_stats allocation<br /> <br /> rx_stats for each arsta is allocated when adding a station.<br /> arsta-&gt;rx_stats will be freed when a station is removed.<br /> <br /> Redundant allocations are occurring when the same station is added<br /> multiple times. This causes ath12k_mac_station_add() to be called<br /> multiple times, and rx_stats is allocated each time. As a result there<br /> is memory leaks.<br /> <br /> Prevent multiple allocations of rx_stats when ath12k_mac_station_add()<br /> is called repeatedly by checking if rx_stats is already allocated<br /> before allocating again. Allocate arsta-&gt;rx_stats if arsta-&gt;rx_stats<br /> is NULL respectively.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1<br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: fix MMIO write access to an invalid page in i40e_clear_hw<br /> <br /> When the device sends a specific input, an integer underflow can occur, leading<br /> to MMIO write access to an invalid page.<br /> <br /> Prevent the integer underflow by changing the type of related variables.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: Revert atm_account_tx() if copy_from_iter_full() fails.<br /> <br /> In vcc_sendmsg(), we account skb-&gt;truesize to sk-&gt;sk_wmem_alloc by<br /> atm_account_tx().<br /> <br /> It is expected to be reverted by atm_pop_raw() later called by<br /> vcc-&gt;dev-&gt;ops-&gt;send(vcc, skb).<br /> <br /> However, vcc_sendmsg() misses the same revert when copy_from_iter_full()<br /> fails, and then we will leak a socket.<br /> <br /> Let&amp;#39;s factorise the revert part as atm_return_tx() and call it in<br /> the failure path.<br /> <br /> Note that the corresponding sk_wmem_alloc operation can be found in<br /> alloc_tx() as of the blamed commit.<br /> <br /> $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~