Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfs: Don&amp;#39;t evict inode under the inode lru traversing context<br /> <br /> The inode reclaiming process(See function prune_icache_sb) collects all<br /> reclaimable inodes and mark them with I_FREEING flag at first, at that<br /> time, other processes will be stuck if they try getting these inodes<br /> (See function find_inode_fast), then the reclaiming process destroy the<br /> inodes by function dispose_list(). Some filesystems(eg. ext4 with<br /> ea_inode feature, ubifs with xattr) may do inode lookup in the inode<br /> evicting callback function, if the inode lookup is operated under the<br /> inode lru traversing context, deadlock problems may happen.<br /> <br /> Case 1: In function ext4_evict_inode(), the ea inode lookup could happen<br /> if ea_inode feature is enabled, the lookup process will be stuck<br /> under the evicting context like this:<br /> <br /> 1. File A has inode i_reg and an ea inode i_ea<br /> 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-&gt;i_ea<br /> 3. Then, following three processes running like this:<br /> <br /> PA PB<br /> echo 2 &gt; /proc/sys/vm/drop_caches<br /> shrink_slab<br /> prune_dcache_sb<br /> // i_reg is added into lru, lru-&gt;i_ea-&gt;i_reg<br /> prune_icache_sb<br /> list_lru_walk_one<br /> inode_lru_isolate<br /> i_ea-&gt;i_state |= I_FREEING // set inode state<br /> inode_lru_isolate<br /> __iget(i_reg)<br /> spin_unlock(&amp;i_reg-&gt;i_lock)<br /> spin_unlock(lru_lock)<br /> rm file A<br /> i_reg-&gt;nlink = 0<br /> iput(i_reg) // i_reg-&gt;nlink is 0, do evict<br /> ext4_evict_inode<br /> ext4_xattr_delete_inode<br /> ext4_xattr_inode_dec_ref_all<br /> ext4_xattr_inode_iget<br /> ext4_iget(i_ea-&gt;i_ino)<br /> iget_locked<br /> find_inode_fast<br /> __wait_on_freeing_inode(i_ea) ----→ AA deadlock<br /> dispose_list // cannot be executed by prune_icache_sb<br /> wake_up_bit(&amp;i_ea-&gt;i_state)<br /> <br /> Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file<br /> deleting process holds BASEHD&amp;#39;s wbuf-&gt;io_mutex while getting the<br /> xattr inode, which could race with inode reclaiming process(The<br /> reclaiming process could try locking BASEHD&amp;#39;s wbuf-&gt;io_mutex in<br /> inode evicting function), then an ABBA deadlock problem would<br /> happen as following:<br /> <br /> 1. File A has inode ia and a xattr(with inode ixa), regular file B has<br /> inode ib and a xattr.<br /> 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-&gt;ixa<br /> 3. Then, following three processes running like this:<br /> <br /> PA PB PC<br /> echo 2 &gt; /proc/sys/vm/drop_caches<br /> shrink_slab<br /> prune_dcache_sb<br /> // ib and ia are added into lru, lru-&gt;ixa-&gt;ib-&gt;ia<br /> prune_icache_sb<br /> list_lru_walk_one<br /> inode_lru_isolate<br /> ixa-&gt;i_state |= I_FREEING // set inode state<br /> inode_lru_isolate<br /> __iget(ib)<br /> spin_unlock(&amp;ib-&gt;i_lock)<br /> spin_unlock(lru_lock)<br /> rm file B<br /> ib-&gt;nlink = 0<br /> rm file A<br /> iput(ia)<br /> ubifs_evict_inode(ia)<br /> ubifs_jnl_delete_inode(ia)<br /> ubifs_jnl_write_inode(ia)<br /> make_reservation(BASEHD) // Lock wbuf-&gt;io_mutex<br /> ubifs_iget(ixa-&gt;i_ino)<br /> iget_locked<br /> find_inode_fast<br /> __wait_on_freeing_inode(ixa)<br /> | iput(ib) // ib-&gt;nlink is 0, do evict<br /> | ubifs_evict_inode<br /> | ubifs_jnl_delete_inode(ib)<br /> ↓ ubifs_jnl_write_inode<br /> ABBA deadlock ←-----make_reservation(BASEHD)<br /> dispose_list // cannot be executed by prune_icache_sb<br /> wake_up_bit(&amp;ixa-&gt;i_state)<br /> <br /> Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING<br /> to pin the inode in memory while inode_lru_isolate(<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration<br /> <br /> re-enumerating full-speed devices after a failed address device command<br /> can trigger a NULL pointer dereference.<br /> <br /> Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size<br /> value during enumeration. Usb core calls usb_ep0_reinit() in this case,<br /> which ends up calling xhci_configure_endpoint().<br /> <br /> On Panther point xHC the xhci_configure_endpoint() function will<br /> additionally check and reserve bandwidth in software. Other hosts do<br /> this in hardware<br /> <br /> If xHC address device command fails then a new xhci_virt_device structure<br /> is allocated as part of re-enabling the slot, but the bandwidth table<br /> pointers are not set up properly here.<br /> This triggers the NULL pointer dereference the next time usb_ep0_reinit()<br /> is called and xhci_configure_endpoint() tries to check and reserve<br /> bandwidth<br /> <br /> [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd<br /> [46710.713699] usb 3-1: Device not responding to setup address.<br /> [46710.917684] usb 3-1: Device not responding to setup address.<br /> [46711.125536] usb 3-1: device not accepting address 5, error -71<br /> [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [46711.125600] #PF: supervisor read access in kernel mode<br /> [46711.125603] #PF: error_code(0x0000) - not-present page<br /> [46711.125606] PGD 0 P4D 0<br /> [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1<br /> [46711.125620] Hardware name: Gigabyte Technology Co., Ltd.<br /> [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]<br /> [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c<br /> <br /> Fix this by making sure bandwidth table pointers are set up correctly<br /> after a failed address device command, and additionally by avoiding<br /> checking for bandwidth in cases like this where no actual endpoints are<br /> added or removed, i.e. only context for default control endpoint 0 is<br /> evaluated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/cpuset: fix panic caused by partcmd_update<br /> <br /> We find a bug as below:<br /> BUG: unable to handle page fault for address: 00000003<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 PID: 358 Comm: bash Tainted: G W I 6.6.0-10893-g60d6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4<br /> RIP: 0010:partition_sched_domains_locked+0x483/0x600<br /> Code: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9<br /> RSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202<br /> RAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80<br /> RBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002<br /> R13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> ? show_regs+0x8c/0xa0<br /> ? __die_body+0x23/0xa0<br /> ? __die+0x3a/0x50<br /> ? page_fault_oops+0x1d2/0x5c0<br /> ? partition_sched_domains_locked+0x483/0x600<br /> ? search_module_extables+0x2a/0xb0<br /> ? search_exception_tables+0x67/0x90<br /> ? kernelmode_fixup_or_oops+0x144/0x1b0<br /> ? __bad_area_nosemaphore+0x211/0x360<br /> ? up_read+0x3b/0x50<br /> ? bad_area_nosemaphore+0x1a/0x30<br /> ? exc_page_fault+0x890/0xd90<br /> ? __lock_acquire.constprop.0+0x24f/0x8d0<br /> ? __lock_acquire.constprop.0+0x24f/0x8d0<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? partition_sched_domains_locked+0x483/0x600<br /> ? partition_sched_domains_locked+0xf0/0x600<br /> rebuild_sched_domains_locked+0x806/0xdc0<br /> update_partition_sd_lb+0x118/0x130<br /> cpuset_write_resmask+0xffc/0x1420<br /> cgroup_file_write+0xb2/0x290<br /> kernfs_fop_write_iter+0x194/0x290<br /> new_sync_write+0xeb/0x160<br /> vfs_write+0x16f/0x1d0<br /> ksys_write+0x81/0x180<br /> __x64_sys_write+0x21/0x30<br /> x64_sys_call+0x2f25/0x4630<br /> do_syscall_64+0x44/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> RIP: 0033:0x7f44a553c887<br /> <br /> It can be reproduced with cammands:<br /> cd /sys/fs/cgroup/<br /> mkdir test<br /> cd test/<br /> echo +cpuset &gt; ../cgroup.subtree_control<br /> echo root &gt; cpuset.cpus.partition<br /> cat /sys/fs/cgroup/cpuset.cpus.effective<br /> 0-3<br /> echo 0-3 &gt; cpuset.cpus // taking away all cpus from root<br /> <br /> This issue is caused by the incorrect rebuilding of scheduling domains.<br /> In this scenario, test/cpuset.cpus.partition should be an invalid root<br /> and should not trigger the rebuilding of scheduling domains. When calling<br /> update_parent_effective_cpumask with partcmd_update, if newmask is not<br /> null, it should recheck newmask whether there are cpus is available<br /> for parect/cs that has tasks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: pata_macio: Fix DMA table overflow<br /> <br /> Kolbjørn and Jonáš reported that their 32-bit PowerMacs were crashing<br /> in pata-macio since commit 09fe2bfa6b83 ("ata: pata_macio: Fix<br /> max_segment_size with PAGE_SIZE == 64K").<br /> <br /> For example:<br /> <br /> kernel BUG at drivers/ata/pata_macio.c:544!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac<br /> ...<br /> NIP pata_macio_qc_prep+0xf4/0x190<br /> LR pata_macio_qc_prep+0xfc/0x190<br /> Call Trace:<br /> 0xc1421660 (unreliable)<br /> ata_qc_issue+0x14c/0x2d4<br /> __ata_scsi_queuecmd+0x200/0x53c<br /> ata_scsi_queuecmd+0x50/0xe0<br /> scsi_queue_rq+0x788/0xb1c<br /> __blk_mq_issue_directly+0x58/0xf4<br /> blk_mq_plug_issue_direct+0x8c/0x1b4<br /> blk_mq_flush_plug_list.part.0+0x584/0x5e0<br /> __blk_flush_plug+0xf8/0x194<br /> __submit_bio+0x1b8/0x2e0<br /> submit_bio_noacct_nocheck+0x230/0x304<br /> btrfs_work_helper+0x200/0x338<br /> process_one_work+0x1a8/0x338<br /> worker_thread+0x364/0x4c0<br /> kthread+0x100/0x104<br /> start_kernel_thread+0x10/0x14<br /> <br /> That commit increased max_segment_size to 64KB, with the justification<br /> that the SCSI core was already using that size when PAGE_SIZE == 64KB,<br /> and that there was existing logic to split over-sized requests.<br /> <br /> However with a sufficiently large request, the splitting logic causes<br /> each sg to be split into two commands in the DMA table, leading to<br /> overflow of the DMA table, triggering the BUG_ON().<br /> <br /> With default settings the bug doesn&amp;#39;t trigger, because the request size<br /> is limited by max_sectors_kb == 1280, however max_sectors_kb can be<br /> increased, and apparently some distros do that by default using udev<br /> rules.<br /> <br /> Fix the bug for 4KB kernels by reverting to the old max_segment_size.<br /> <br /> For 64KB kernels the sg_tablesize needs to be halved, to allow for the<br /> possibility that each sg will be split into two.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Free job before xe_exec_queue_put<br /> <br /> Free job depends on job-&gt;vm being valid, the last xe_exec_queue_put can<br /> destroy the VM. Prevent UAF by freeing job before xe_exec_queue_put.<br /> <br /> (cherry picked from commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix missing workqueue destroy in xe_gt_pagefault<br /> <br /> On driver reload we never free up the memory for the pagefault and<br /> access counter workqueues. Add those destroy calls here.<br /> <br /> (cherry picked from commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix opregion leak<br /> <br /> Being part o the display, ideally the setup and cleanup would be done by<br /> display itself. However this is a bigger refactor that needs to be done<br /> on both i915 and xe. For now, just fix the leak:<br /> <br /> unreferenced object 0xffff8881a0300008 (size 192):<br /> comm "modprobe", pid 4354, jiffies 4295647021<br /> hex dump (first 32 bytes):<br /> 00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff ...&amp;#39;............<br /> 18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 99260e31):<br /> [] kmemleak_alloc+0x4b/0x80<br /> [] kmalloc_trace_noprof+0x312/0x3d0<br /> [] intel_opregion_setup+0x89/0x700 [xe]<br /> [] xe_display_init_noirq+0x2f/0x90 [xe]<br /> [] xe_device_probe+0x7a3/0xbf0 [xe]<br /> [] xe_pci_probe+0x333/0x5b0 [xe]<br /> [] local_pci_probe+0x48/0xb0<br /> [] pci_device_probe+0xc8/0x280<br /> [] really_probe+0xf8/0x390<br /> [] __driver_probe_device+0x8a/0x170<br /> [] driver_probe_device+0x23/0xb0<br /> [] __driver_attach+0xc7/0x190<br /> [] bus_for_each_dev+0x7d/0xd0<br /> [] driver_attach+0x1e/0x30<br /> [] bus_add_driver+0x117/0x250<br /> <br /> (cherry picked from commit 6f4e43a2f771b737d991142ec4f6d4b7ff31fbb4)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> workqueue: Fix UBSAN &amp;#39;subtraction overflow&amp;#39; error in shift_and_mask()<br /> <br /> UBSAN reports the following &amp;#39;subtraction overflow&amp;#39; error when booting<br /> in a virtual machine on Android:<br /> <br /> | Internal error: UBSAN: integer subtraction overflow: 00000000f2005515 [#1] PREEMPT SMP<br /> | Modules linked in:<br /> | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-00006-g3cbe9e5abd46-dirty #4<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : cancel_delayed_work+0x34/0x44<br /> | lr : cancel_delayed_work+0x2c/0x44<br /> | sp : ffff80008002ba60<br /> | x29: ffff80008002ba60 x28: 0000000000000000 x27: 0000000000000000<br /> | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 0000000000000000 x22: 0000000000000000 x21: ffff1f65014cd3c0<br /> | x20: ffffc0e84c9d0da0 x19: ffffc0e84cab3558 x18: ffff800080009058<br /> | x17: 00000000247ee1f8 x16: 00000000247ee1f8 x15: 00000000bdcb279d<br /> | x14: 0000000000000001 x13: 0000000000000075 x12: 00000a0000000000<br /> | x11: ffff1f6501499018 x10: 00984901651fffff x9 : ffff5e7cc35af000<br /> | x8 : 0000000000000001 x7 : 3d4d455453595342 x6 : 000000004e514553<br /> | x5 : ffff1f6501499265 x4 : ffff1f650ff60b10 x3 : 0000000000000620<br /> | x2 : ffff80008002ba78 x1 : 0000000000000000 x0 : 0000000000000000<br /> | Call trace:<br /> | cancel_delayed_work+0x34/0x44<br /> | deferred_probe_extend_timeout+0x20/0x70<br /> | driver_register+0xa8/0x110<br /> | __platform_driver_register+0x28/0x3c<br /> | syscon_init+0x24/0x38<br /> | do_one_initcall+0xe4/0x338<br /> | do_initcall_level+0xac/0x178<br /> | do_initcalls+0x5c/0xa0<br /> | do_basic_setup+0x20/0x30<br /> | kernel_init_freeable+0x8c/0xf8<br /> | kernel_init+0x28/0x1b4<br /> | ret_from_fork+0x10/0x20<br /> | Code: f9000fbf 97fffa2f 39400268 37100048 (d42aa2a0)<br /> | ---[ end trace 0000000000000000 ]---<br /> | Kernel panic - not syncing: UBSAN: integer subtraction overflow: Fatal exception<br /> <br /> This is due to shift_and_mask() using a signed immediate to construct<br /> the mask and being called with a shift of 31 (WORK_OFFQ_POOL_SHIFT) so<br /> that it ends up decrementing from INT_MIN.<br /> <br /> Use an unsigned constant &amp;#39;1U&amp;#39; to generate the mask in shift_and_mask().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix double DMA unmapping for XDP_REDIRECT<br /> <br /> Remove the dma_unmap_page_attrs() call in the driver&amp;#39;s XDP_REDIRECT<br /> code path. This should have been removed when we let the page pool<br /> handle the DMA mapping. This bug causes the warning:<br /> <br /> WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100<br /> CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu<br /> Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024<br /> RIP: 0010:iommu_dma_unmap_page+0xd5/0x100<br /> Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9<br /> RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c<br /> R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000<br /> R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002<br /> FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0<br /> ? show_regs+0x6d/0x80<br /> ? __warn+0x89/0x150<br /> ? iommu_dma_unmap_page+0xd5/0x100<br /> ? report_bug+0x16a/0x190<br /> ? handle_bug+0x51/0xa0<br /> ? exc_invalid_op+0x18/0x80<br /> ? iommu_dma_unmap_page+0xd5/0x100<br /> ? iommu_dma_unmap_page+0x35/0x100<br /> dma_unmap_page_attrs+0x55/0x220<br /> ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f<br /> bnxt_rx_xdp+0x237/0x520 [bnxt_en]<br /> bnxt_rx_pkt+0x640/0xdd0 [bnxt_en]<br /> __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en]<br /> bnxt_poll+0xaa/0x1e0 [bnxt_en]<br /> __napi_poll+0x33/0x1e0<br /> net_rx_action+0x18a/0x2f0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Validate TA binary size<br /> <br /> Add TA binary size validation to avoid OOB write.<br /> <br /> (cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails<br /> <br /> If the dpu_format_populate_layout() fails, then FB is prepared, but not<br /> cleaned up. This ends up leaking the pin_count on the GEM object and<br /> causes a splat during DRM file closure:<br /> <br /> msm_obj-&gt;pin_count<br /> WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc<br /> [...]<br /> Call trace:<br /> update_lru_locked+0xc4/0xcc<br /> put_pages+0xac/0x100<br /> msm_gem_free_object+0x138/0x180<br /> drm_gem_object_free+0x1c/0x30<br /> drm_gem_object_handle_put_unlocked+0x108/0x10c<br /> drm_gem_object_release_handle+0x58/0x70<br /> idr_for_each+0x68/0xec<br /> drm_gem_release+0x28/0x40<br /> drm_file_free+0x174/0x234<br /> drm_release+0xb0/0x160<br /> __fput+0xc0/0x2c8<br /> __fput_sync+0x50/0x5c<br /> __arm64_sys_close+0x38/0x7c<br /> invoke_syscall+0x48/0x118<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x4c/0x120<br /> el0t_64_sync_handler+0x100/0x12c<br /> el0t_64_sync+0x190/0x194<br /> irq event stamp: 129818<br /> hardirqs last enabled at (129817): [] console_unlock+0x118/0x124<br /> hardirqs last disabled at (129818): [] el1_dbg+0x24/0x8c<br /> softirqs last enabled at (129808): [] handle_softirqs+0x4c8/0x4e8<br /> softirqs last disabled at (129785): [] __do_softirq+0x14/0x20<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/600714/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: validate vlan header<br /> <br /> Ensure there is sufficient room to access the protocol field of the<br /> VLAN header, validate it once before the flowtable lookup.<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32<br /> nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626<br /> nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]<br /> nf_ingress net/core/dev.c:5440 [inline]