Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP<br /> <br /> Fixes OOPS on boards with ANX9805 DP encoders.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/sysv: Null check to prevent null-ptr-deref bug<br /> <br /> sb_getblk(inode-&gt;i_sb, parent) return a null ptr and taking lock on<br /> that leads to the null-ptr-deref bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix an uninit variable access bug in __ip6_make_skb()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]<br /> BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]<br /> BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]<br /> BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956<br /> arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]<br /> arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]<br /> atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]<br /> __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956<br /> ip6_finish_skb include/net/ipv6.h:1122 [inline]<br /> ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987<br /> rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579<br /> rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922<br /> inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530<br /> __sys_sendmsg net/socket.c:2559 [inline]<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988<br /> kmalloc_reserve net/core/skbuff.c:492 [inline]<br /> __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565<br /> alloc_skb include/linux/skbuff.h:1270 [inline]<br /> __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684<br /> ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854<br /> rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915<br /> inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530<br /> __sys_sendmsg net/socket.c:2559 [inline]<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> It is because icmp6hdr does not in skb linear region under the scenario<br /> of SOCK_RAW socket. Access icmp6_hdr(skb)-&gt;icmp6_type directly will<br /> trigger the uninit variable access bug.<br /> <br /> Use a local variable icmp6_type to carry the correct value in different<br /> scenarios.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()<br /> <br /> &amp;#39;read&amp;#39; is freed when it is known to be NULL, but not when a read error<br /> occurs.<br /> <br /> Revert the logic to avoid a small leak, should a m920x_read() call fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT<br /> <br /> lppaca_shared_proc() takes a pointer to the lppaca which is typically<br /> accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads<br /> to checking if preemption is enabled, for example:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693<br /> caller is lparcfg_data+0x408/0x19a0<br /> CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2<br /> Call Trace:<br /> dump_stack_lvl+0x154/0x200 (unreliable)<br /> check_preemption_disabled+0x214/0x220<br /> lparcfg_data+0x408/0x19a0<br /> ...<br /> <br /> This isn&amp;#39;t actually a problem however, as it does not matter which<br /> lppaca is accessed, the shared proc state will be the same.<br /> vcpudispatch_stats_procfs_init() already works around this by disabling<br /> preemption, but the lparcfg code does not, erroring any time<br /> /proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.<br /> <br /> Instead of disabling preemption on the caller side, rework<br /> lppaca_shared_proc() to not take a pointer and instead directly access<br /> the lppaca, bypassing any potential preemption checks.<br /> <br /> [mpe: Rework to avoid needing a definition in paca.h and lppaca.h]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> debugobjects: Don&amp;#39;t wake up kswapd from fill_pool()<br /> <br /> syzbot is reporting a lockdep warning in fill_pool() because the allocation<br /> from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)<br /> and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.<br /> <br /> Since fill_pool() might be called with arbitrary locks held, fill_pool()<br /> should not assume that acquiring kswapd_wait::lock is safe.<br /> <br /> Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for<br /> !__GFP_DIRECT_RECLAIM allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: double free xprt_ctxt while still in use<br /> <br /> When an RPC request is deferred, the rq_xprt_ctxt pointer is moved out<br /> of the svc_rqst into the svc_deferred_req.<br /> When the deferred request is revisited, the pointer is copied into<br /> the new svc_rqst - and also remains in the svc_deferred_req.<br /> <br /> In the (rare?) case that the request is deferred a second time, the old<br /> svc_deferred_req is reused - it still has all the correct content.<br /> However in that case the rq_xprt_ctxt pointer is NOT cleared so that<br /> when xpo_release_xprt is called, the ctxt is freed (UDP) or possible<br /> added to a free list (RDMA).<br /> When the deferred request is revisited for a second time, it will<br /> reference this ctxt which may be invalid, and the free the object a<br /> second time which is likely to oops.<br /> <br /> So change svc_defer() to *always* clear rq_xprt_ctxt, and assert that<br /> the value is now stored in the svc_deferred_req.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: usb: siano: Fix use after free bugs caused by do_submit_urb<br /> <br /> There are UAF bugs caused by do_submit_urb(). One of the KASan reports<br /> is shown below:<br /> <br /> [ 36.403605] BUG: KASAN: use-after-free in worker_thread+0x4a2/0x890<br /> [ 36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49<br /> [ 36.408316]<br /> [ 36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237ad1d4-dir8<br /> [ 36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584<br /> [ 36.416157] Workqueue: 0x0 (events)<br /> [ 36.417654] Call Trace:<br /> [ 36.418546] <br /> [ 36.419320] dump_stack_lvl+0x96/0xd0<br /> [ 36.420522] print_address_description+0x75/0x350<br /> [ 36.421992] print_report+0x11b/0x250<br /> [ 36.423174] ? _raw_spin_lock_irqsave+0x87/0xd0<br /> [ 36.424806] ? __virt_addr_valid+0xcf/0x170<br /> [ 36.426069] ? worker_thread+0x4a2/0x890<br /> [ 36.427355] kasan_report+0x131/0x160<br /> [ 36.428556] ? worker_thread+0x4a2/0x890<br /> [ 36.430053] worker_thread+0x4a2/0x890<br /> [ 36.431297] ? worker_clr_flags+0x90/0x90<br /> [ 36.432479] kthread+0x166/0x190<br /> [ 36.433493] ? kthread_blkcg+0x50/0x50<br /> [ 36.434669] ret_from_fork+0x22/0x30<br /> [ 36.435923] <br /> [ 36.436684]<br /> [ 36.437215] Allocated by task 24:<br /> [ 36.438289] kasan_set_track+0x50/0x80<br /> [ 36.439436] __kasan_kmalloc+0x89/0xa0<br /> [ 36.440566] smsusb_probe+0x374/0xc90<br /> [ 36.441920] usb_probe_interface+0x2d1/0x4c0<br /> [ 36.443253] really_probe+0x1d5/0x580<br /> [ 36.444539] __driver_probe_device+0xe3/0x130<br /> [ 36.446085] driver_probe_device+0x49/0x220<br /> [ 36.447423] __device_attach_driver+0x19e/0x1b0<br /> [ 36.448931] bus_for_each_drv+0xcb/0x110<br /> [ 36.450217] __device_attach+0x132/0x1f0<br /> [ 36.451470] bus_probe_device+0x59/0xf0<br /> [ 36.452563] device_add+0x4ec/0x7b0<br /> [ 36.453830] usb_set_configuration+0xc63/0xe10<br /> [ 36.455230] usb_generic_driver_probe+0x3b/0x80<br /> [ 36.456166] printk: console [ttyGS0] disabled<br /> [ 36.456569] usb_probe_device+0x90/0x110<br /> [ 36.459523] really_probe+0x1d5/0x580<br /> [ 36.461027] __driver_probe_device+0xe3/0x130<br /> [ 36.462465] driver_probe_device+0x49/0x220<br /> [ 36.463847] __device_attach_driver+0x19e/0x1b0<br /> [ 36.465229] bus_for_each_drv+0xcb/0x110<br /> [ 36.466466] __device_attach+0x132/0x1f0<br /> [ 36.467799] bus_probe_device+0x59/0xf0<br /> [ 36.469010] device_add+0x4ec/0x7b0<br /> [ 36.470125] usb_new_device+0x863/0xa00<br /> [ 36.471374] hub_event+0x18c7/0x2220<br /> [ 36.472746] process_one_work+0x34c/0x5b0<br /> [ 36.474041] worker_thread+0x4b7/0x890<br /> [ 36.475216] kthread+0x166/0x190<br /> [ 36.476267] ret_from_fork+0x22/0x30<br /> [ 36.477447]<br /> [ 36.478160] Freed by task 24:<br /> [ 36.479239] kasan_set_track+0x50/0x80<br /> [ 36.480512] kasan_save_free_info+0x2b/0x40<br /> [ 36.481808] ____kasan_slab_free+0x122/0x1a0<br /> [ 36.483173] __kmem_cache_free+0xc4/0x200<br /> [ 36.484563] smsusb_term_device+0xcd/0xf0<br /> [ 36.485896] smsusb_probe+0xc85/0xc90<br /> [ 36.486976] usb_probe_interface+0x2d1/0x4c0<br /> [ 36.488303] really_probe+0x1d5/0x580<br /> [ 36.489498] __driver_probe_device+0xe3/0x130<br /> [ 36.491140] driver_probe_device+0x49/0x220<br /> [ 36.492475] __device_attach_driver+0x19e/0x1b0<br /> [ 36.493988] bus_for_each_drv+0xcb/0x110<br /> [ 36.495171] __device_attach+0x132/0x1f0<br /> [ 36.496617] bus_probe_device+0x59/0xf0<br /> [ 36.497875] device_add+0x4ec/0x7b0<br /> [ 36.498972] usb_set_configuration+0xc63/0xe10<br /> [ 36.500264] usb_generic_driver_probe+0x3b/0x80<br /> [ 36.501740] usb_probe_device+0x90/0x110<br /> [ 36.503084] really_probe+0x1d5/0x580<br /> [ 36.504241] __driver_probe_device+0xe3/0x130<br /> [ 36.505548] driver_probe_device+0x49/0x220<br /> [ 36.506766] __device_attach_driver+0x19e/0x1b0<br /> [ 36.508368] bus_for_each_drv+0xcb/0x110<br /> [ 36.509646] __device_attach+0x132/0x1f0<br /> [ 36.510911] bus_probe_device+0x59/0xf0<br /> [ 36.512103] device_add+0x4ec/0x7b0<br /> [ 36.513215] usb_new_device+0x863/0xa00<br /> [ 36.514736] hub_event+0x18c7/0x2220<br /> [ 36.516130] process_one_work+<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Don&amp;#39;t leak a resource on eviction error<br /> <br /> On eviction errors other than -EMULTIHOP we were leaking a resource.<br /> Fix.<br /> <br /> v2:<br /> - Avoid yet another goto (Andi Shyti)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sh: dma: Fix DMA channel offset calculation<br /> <br /> Various SoCs of the SH3, SH4 and SH4A family, which use this driver,<br /> feature a differing number of DMA channels, which can be distributed<br /> between up to two DMAC modules. The existing implementation fails to<br /> correctly accommodate for all those variations, resulting in wrong<br /> channel offset calculations and leading to kernel panics.<br /> <br /> Rewrite dma_base_addr() in order to properly calculate channel offsets<br /> in a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so that<br /> the correct DMAC module base is selected for the DMAOR register.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: fix a memory corruption in extended buffer descriptor mode<br /> <br /> For quite some time we were chasing a bug which looked like a sudden<br /> permanent failure of networking and mmc on some of our devices.<br /> The bug was very sensitive to any software changes and even more to<br /> any kernel debug options.<br /> <br /> Finally we got a setup where the problem was reproducible with<br /> CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:<br /> <br /> [ 16.992082] ------------[ cut here ]------------<br /> [ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes]<br /> [ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900<br /> [ 17.018977] Modules linked in: xxxxx<br /> [ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28<br /> [ 17.045345] Hardware name: xxxxx<br /> [ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)<br /> [ 17.054322] pc : check_unmap+0x6a0/0x900<br /> [ 17.058243] lr : check_unmap+0x6a0/0x900<br /> [ 17.062163] sp : ffffffc010003c40<br /> [ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c<br /> [ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800<br /> [ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8<br /> [ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750<br /> [ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000<br /> [ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010<br /> [ 17.097343] x17: 0000000000000000 x16: 0000000000000000<br /> [ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720<br /> [ 17.107959] x13: 0720072007200720 x12: 0720072007200720<br /> [ 17.113261] x11: 0720072007200720 x10: 0720072007200720<br /> [ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d<br /> [ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098<br /> [ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000<br /> [ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370<br /> [ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000<br /> [ 17.145082] Call trace:<br /> [ 17.147524] check_unmap+0x6a0/0x900<br /> [ 17.151091] debug_dma_unmap_page+0x88/0x90<br /> [ 17.155266] gem_rx+0x114/0x2f0<br /> [ 17.158396] macb_poll+0x58/0x100<br /> [ 17.161705] net_rx_action+0x118/0x400<br /> [ 17.165445] __do_softirq+0x138/0x36c<br /> [ 17.169100] irq_exit+0x98/0xc0<br /> [ 17.172234] __handle_domain_irq+0x64/0xc0<br /> [ 17.176320] gic_handle_irq+0x5c/0xc0<br /> [ 17.179974] el1_irq+0xb8/0x140<br /> [ 17.183109] xiic_process+0x5c/0xe30<br /> [ 17.186677] irq_thread_fn+0x28/0x90<br /> [ 17.190244] irq_thread+0x208/0x2a0<br /> [ 17.193724] kthread+0x130/0x140<br /> [ 17.196945] ret_from_fork+0x10/0x20<br /> [ 17.200510] ---[ end trace 7240980785f81d6f ]---<br /> <br /> [ 237.021490] ------------[ cut here ]------------<br /> [ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b<br /> [ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240<br /> [ 237.041802] Modules linked in: xxxxx<br /> [ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28<br /> [ 237.068941] Hardware name: xxxxx<br /> [ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)<br /> [ 237.077900] pc : add_dma_entry+0x214/0x240<br /> [ 237.081986] lr : add_dma_entry+0x214/0x240<br /> [ 237.086072] sp : ffffffc010003c30<br /> [ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00<br /> [ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0<br /> [ 237.099987] x25: 0000000000000002 x24: 0000000000000000<br /> [ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00<br /> [ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600<br /> [ 237.115897] x19: 00000000ffffffef x18: 0000000000000010<br /> [ 237.121201] x17: 0000000000000000 x16: 0000000000000000<br /> [ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720<br /> [ 237.131807] x13: 0720072007200720 x12: 0720072007200720<br /> [ 237.137111] x11: 0720072007200720 x10: 0720072007200720<br /> [ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259<br /> [ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000<br /> [ 237.15302<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential oops in cifs_oplock_break<br /> <br /> With deferred close we can have closes that race with lease breaks,<br /> and so with the current checks for whether to send the lease response,<br /> oplock_response(), this can mean that an unmount (kill_sb) can occur<br /> just before we were checking if the tcon-&gt;ses is valid. See below:<br /> <br /> [Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]<br /> [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39<br /> [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206<br /> [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009<br /> [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188<br /> [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900<br /> [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138<br /> [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000<br /> [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000<br /> [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0<br /> [Fri Aug 4 04:12:50 2023] Call Trace:<br /> [Fri Aug 4 04:12:50 2023] <br /> [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0<br /> [Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0<br /> [Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0<br /> [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150<br /> [Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50<br /> [Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30<br /> [Fri Aug 4 04:12:50 2023] <br /> <br /> To fix this change the ordering of the checks before sending the oplock_response<br /> to first check if the openFileList is empty.