Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Don&amp;#39;t leak a resource on swapout move error<br /> <br /> If moving the bo to system for swapout failed, we were leaking<br /> a resource. Fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix infinite loop in nilfs_mdt_get_block()<br /> <br /> If the disk image that nilfs2 mounts is corrupted and a virtual block<br /> address obtained by block lookup for a metadata file is invalid,<br /> nilfs_bmap_lookup_at_level() may return the same internal return code as<br /> -ENOENT, meaning the block does not exist in the metadata file.<br /> <br /> This duplication of return codes confuses nilfs_mdt_get_block(), causing<br /> it to read and create a metadata block indefinitely.<br /> <br /> In particular, if this happens to the inode metadata file, ifile,<br /> semaphore i_rwsem can be left held, causing task hangs in lock_mount.<br /> <br /> Fix this issue by making nilfs_bmap_lookup_at_level() treat virtual block<br /> address translation failures with -ENOENT as metadata corruption instead<br /> of returning the error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix NULL-deref on snapshot tear down<br /> <br /> In case of early initialisation errors and on platforms that do not use<br /> the DPU controller, the deinitilisation code can be called with the kms<br /> pointer set to NULL.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525099/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: synchronize atomic write aborts<br /> <br /> To fix a race condition between atomic write aborts, I use the inode<br /> lock and make COW inode to be re-usable thoroughout the whole<br /> atomic file inode lifetime.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dccp: fix data-race around dp-&gt;dccps_mss_cache<br /> <br /> dccp_sendmsg() reads dp-&gt;dccps_mss_cache before locking the socket.<br /> Same thing in do_dccp_getsockopt().<br /> <br /> Add READ_ONCE()/WRITE_ONCE() annotations,<br /> and change dccp_sendmsg() to check again dccps_mss_cache<br /> after socket is locked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: early: xhci-dbc: Fix a potential out-of-bound memory access<br /> <br /> If xdbc_bulk_write() fails, the values in &amp;#39;buf&amp;#39; can be anything. So the<br /> string is not guaranteed to be NULL terminated when xdbc_trace() is called.<br /> <br /> Reserve an extra byte, which will be zeroed automatically because &amp;#39;buf&amp;#39; is<br /> a static variable, in order to avoid troubles, should it happen.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: read sk-&gt;sk_family once in sk_mc_loop()<br /> <br /> syzbot is playing with IPV6_ADDRFORM quite a lot these days,<br /> and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()<br /> <br /> We have many more similar issues to fix.<br /> <br /> WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260<br /> Modules linked in:<br /> CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023<br /> Workqueue: events_power_efficient gc_worker<br /> RIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782<br /> Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48<br /> RSP: 0018:ffffc90000388530 EFLAGS: 00010246<br /> RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980<br /> RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011<br /> RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65<br /> R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000<br /> R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000<br /> FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> [] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83<br /> [] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline]<br /> [] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211<br /> [] NF_HOOK_COND include/linux/netfilter.h:298 [inline]<br /> [] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232<br /> [] dst_output include/net/dst.h:444 [inline]<br /> [] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161<br /> [] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline]<br /> [] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]<br /> [] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]<br /> [] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677<br /> [] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229<br /> [] netdev_start_xmit include/linux/netdevice.h:4925 [inline]<br /> [] xmit_one net/core/dev.c:3644 [inline]<br /> [] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660<br /> [] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342<br /> [] qdisc_restart net/sched/sch_generic.c:407 [inline]<br /> [] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415<br /> [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125<br /> [] net_tx_action+0x7ac/0x940 net/core/dev.c:5247<br /> [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599<br /> [] invoke_softirq kernel/softirq.c:430 [inline]<br /> [] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683<br /> [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix null-ptr-deref in raid10_sync_request<br /> <br /> init_resync() inits mempool and sets conf-&gt;have_replacemnt at the beginning<br /> of sync, close_sync() frees the mempool when sync is completed.<br /> <br /> After [1] recovery might be skipped and init_resync() is called but<br /> close_sync() is not. null-ptr-deref occurs with r10bio-&gt;dev[i].repl_bio.<br /> <br /> The following is one way to reproduce the issue.<br /> <br /> 1) create a array, wait for resync to complete, mddev-&gt;recovery_cp is set<br /> to MaxSector.<br /> 2) recovery is woken and it is skipped. conf-&gt;have_replacement is set to<br /> 0 in init_resync(). close_sync() not called.<br /> 3) some io errors and rdev A is set to WantReplacement.<br /> 4) a new device is added and set to A&amp;#39;s replacement.<br /> 5) recovery is woken, A have replacement, but conf-&gt;have_replacemnt is<br /> 0. r10bio-&gt;dev[i].repl_bio will not be alloced and null-ptr-deref<br /> occurs.<br /> <br /> Fix it by not calling init_resync() if recovery skipped.<br /> <br /> [1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix NULL ptr deref by checking new_crtc_state<br /> <br /> intel_atomic_get_new_crtc_state can return NULL, unless crtc state wasn&amp;#39;t<br /> obtained previously with intel_atomic_get_crtc_state, so we must check it<br /> for NULLness here, just as in many other places, where we can&amp;#39;t guarantee<br /> that intel_atomic_get_crtc_state was called.<br /> We are currently getting NULL ptr deref because of that, so this fix was<br /> confirmed to help.<br /> <br /> (cherry picked from commit 1d5b09f8daf859247a1ea65b0d732a24d88980d8)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ina2xx: avoid NULL pointer dereference on OF device match<br /> <br /> The affected lines were resulting in a NULL pointer dereference on our<br /> platform because the device tree contained the following list of<br /> compatible strings:<br /> <br /> power-sensor@40 {<br /> compatible = "ti,ina232", "ti,ina231";<br /> ...<br /> };<br /> <br /> Since the driver doesn&amp;#39;t declare a compatible string "ti,ina232", the OF<br /> matching succeeds on "ti,ina231". But the I2C device ID info is<br /> populated via the first compatible string, cf. modalias population in<br /> of_i2c_get_board_info(). Since there is no "ina232" entry in the legacy<br /> I2C device ID table either, the struct i2c_device_id *id pointer in the<br /> probe function is NULL.<br /> <br /> Fix this by using the already populated type variable instead, which<br /> points to the proper driver data. Since the name is also wanted, add a<br /> generic one to the ina2xx_config table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix skb refcnt race after locking changes<br /> <br /> There is a race where skb&amp;#39;s from the sk_psock_backlog can be referenced<br /> after userspace side has already skb_consumed() the sk_buff and its refcnt<br /> dropped to zer0 causing use after free.<br /> <br /> The flow is the following:<br /> <br /> while ((skb = skb_peek(&amp;psock-&gt;ingress_skb))<br /> sk_psock_handle_Skb(psock, skb, ..., ingress)<br /> if (!ingress) ...<br /> sk_psock_skb_ingress<br /> sk_psock_skb_ingress_enqueue(skb)<br /> msg-&gt;skb = skb<br /> sk_psock_queue_msg(psock, msg)<br /> skb_dequeue(&amp;psock-&gt;ingress_skb)<br /> <br /> The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is<br /> what the application reads when recvmsg() is called. An application can<br /> read this anytime after the msg is placed on the queue. The recvmsg hook<br /> will also read msg-&gt;skb and then after user space reads the msg will call<br /> consume_skb(skb) on it effectively free&amp;#39;ing it.<br /> <br /> But, the race is in above where backlog queue still has a reference to<br /> the skb and calls skb_dequeue(). If the skb_dequeue happens after the<br /> user reads and free&amp;#39;s the skb we have a use after free.<br /> <br /> The !ingress case does not suffer from this problem because it uses<br /> sendmsg_*(sk, msg) which does not pass the sk_buff further down the<br /> stack.<br /> <br /> The following splat was observed with &amp;#39;test_progs -t sockmap_listen&amp;#39;:<br /> <br /> [ 1022.710250][ T2556] general protection fault, ...<br /> [...]<br /> [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog<br /> [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80<br /> [ 1022.713653][ T2556] Code: ...<br /> [...]<br /> [ 1022.720699][ T2556] Call Trace:<br /> [ 1022.720984][ T2556] <br /> [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M<br /> [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0<br /> [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30<br /> [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80<br /> [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300<br /> [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0<br /> [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0<br /> [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10<br /> [ 1022.724386][ T2556] kthread+0xfd/0x130<br /> [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10<br /> [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50<br /> [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10<br /> [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30<br /> [ 1022.726201][ T2556] <br /> <br /> To fix we add an skb_get() before passing the skb to be enqueued in the<br /> engress queue. This bumps the skb-&gt;users refcnt so that consume_skb()<br /> and kfree_skb will not immediately free the sk_buff. With this we can<br /> be sure the skb is still around when we do the dequeue. Then we just<br /> need to decrement the refcnt or free the skb in the backlog case which<br /> we do by calling kfree_skb() on the ingress case as well as the sendmsg<br /> case.<br /> <br /> Before locking change from fixes tag we had the sock locked so we<br /> couldn&amp;#39;t race with user and there was no issue here.