Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: check return value of con2fb_acquire_newinfo()<br /> <br /> If fbcon_open() fails when called from con2fb_acquire_newinfo() then<br /> info-&gt;fbcon_par pointer remains NULL which is later dereferenced.<br /> <br /> Add check for return value of the function con2fb_acquire_newinfo() to<br /> avoid it.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore: ram_core: fix incorrect success return when vmap() fails<br /> <br /> In persistent_ram_vmap(), vmap() may return NULL on failure.<br /> <br /> If offset is non-zero, adding offset_in_page(start) causes the function<br /> to return a non-NULL pointer even though the mapping failed.<br /> persistent_ram_buffer_map() therefore incorrectly returns success.<br /> <br /> Subsequent access to prz-&gt;buffer may dereference an invalid address<br /> and cause crashes.<br /> <br /> Add proper NULL checking for vmap() failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: validate length in dlm_search_rsb_tree<br /> <br /> The len parameter in dlm_dump_rsb_name() is not validated and comes<br /> from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can<br /> cause out-of-bounds write in dlm_search_rsb_tree().<br /> <br /> Add length validation to prevent potential buffer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: mixer: oss: Add card disconnect checkpoints<br /> <br /> ALSA OSS mixer layer calls the kcontrol ops rather individually, and<br /> pending calls might be not always caught at disconnecting the device.<br /> <br /> For avoiding the potential UAF scenarios, add sanity checks of the<br /> card disconnection at each entry point of OSS mixer accesses. The<br /> rwsem is taken just before that check, hence the rest context should<br /> be covered by that properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: fix circular locking dependency in run_unpack_ex<br /> <br /> Syzbot reported a circular locking dependency between wnd-&gt;rw_lock<br /> (sbi-&gt;used.bitmap) and ni-&gt;file.run_lock.<br /> <br /> The deadlock scenario:<br /> 1. ntfs_extend_mft() takes ni-&gt;file.run_lock then wnd-&gt;rw_lock.<br /> 2. run_unpack_ex() takes wnd-&gt;rw_lock then tries to acquire<br /> ni-&gt;file.run_lock inside ntfs_refresh_zone().<br /> <br /> This creates an AB-BA deadlock.<br /> <br /> Fix this by using down_read_trylock() instead of down_read() when<br /> acquiring run_lock in run_unpack_ex(). If the lock is contended,<br /> skip ntfs_refresh_zone() - the MFT zone will be refreshed on the<br /> next MFT operation. This breaks the circular dependency since we<br /> never block waiting for run_lock while holding wnd-&gt;rw_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/umem: Fix double dma_buf_unpin in failure path<br /> <br /> In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to<br /> ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf<br /> is immediately unpinned but the umem_dmabuf-&gt;pinned flag is still<br /> set. Then, when ib_umem_release() is called, it calls<br /> ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again.<br /> <br /> Fix this by removing the immediate unpin upon failure and just let<br /> the ib_umem_release/revoke path handle it. This also ensures the<br /> proper unmap-unpin unwind ordering if the dmabuf_map_pages call<br /> happened to fail due to dma_resv_wait_timeout (and therefore has<br /> a non-NULL umem_dmabuf-&gt;sgt).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: verify the previous kernel&amp;#39;s IMA buffer lies in addressable RAM<br /> <br /> Patch series "Address page fault in ima_restore_measurement_list()", v3.<br /> <br /> When the second-stage kernel is booted via kexec with a limiting command<br /> line such as "mem=" we observe a pafe fault that happens.<br /> <br /> BUG: unable to handle page fault for address: ffff97793ff47000<br /> RIP: ima_restore_measurement_list+0xdc/0x45a<br /> #PF: error_code(0x0000) not-present page<br /> <br /> This happens on x86_64 only, as this is already fixed in aarch64 in<br /> commit: cbf9c4b9617b ("of: check previous kernel&amp;#39;s ima-kexec-buffer<br /> against memory bounds")<br /> <br /> <br /> This patch (of 3):<br /> <br /> When the second-stage kernel is booted with a limiting command line (e.g. <br /> "mem="), the IMA measurement buffer handed over from the previous<br /> kernel may fall outside the addressable RAM of the new kernel. Accessing<br /> such a buffer can fault during early restore.<br /> <br /> Introduce a small generic helper, ima_validate_range(), which verifies<br /> that a physical [start, end] range for the previous-kernel IMA buffer lies<br /> within addressable memory:<br /> - On x86, use pfn_range_is_mapped().<br /> - On OF based architectures, use page_is_ram().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: handle attr_set_size() errors when truncating files<br /> <br /> If attr_set_size() fails while truncating down, the error is silently<br /> ignored and the inode may be left in an inconsistent state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ti_fpc202: fix a potential memory leak in probe function<br /> <br /> Use for_each_child_of_node_scoped() to simplify the code and ensure the<br /> device node reference is automatically released when the loop scope<br /> ends.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read()<br /> <br /> In the function bcm_vk_read(), the pointer entry is checked, indicating<br /> that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the<br /> following code may cause null-pointer dereferences:<br /> <br /> struct vk_msg_blk tmp_msg = entry-&gt;to_h_msg[0];<br /> set_msg_id(&amp;tmp_msg, entry-&gt;usr_msg_id);<br /> tmp_msg.size = entry-&gt;to_h_blks - 1;<br /> <br /> To prevent these possible null-pointer dereferences, copy to_h_msg,<br /> usr_msg_id, and to_h_blks from iter into temporary variables, and return<br /> these temporary variables to the application instead of accessing them<br /> through a potentially NULL entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: nlink overflow in jfs_rename<br /> <br /> If nlink is maximal for a directory (-1) and inside that directory you<br /> perform a rename for some child directory (not moving from the parent),<br /> then the nlink of the first directory is first incremented and later<br /> decremented. Normally this is fine, but when nlink = -1 this causes a<br /> wrap around to 0, and then drop_nlink issues a warning.<br /> <br /> After applying the patch syzbot no longer issues any warnings. I also<br /> ran some basic fs tests to look for any regressions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/ras: Move ras data alloc before bad page check<br /> <br /> In the rare event if eeprom has only invalid address entries,<br /> allocation is skipped, this causes following NULL pointer issue<br /> [ 547.103445] BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> [ 547.118897] #PF: supervisor read access in kernel mode<br /> [ 547.130292] #PF: error_code(0x0000) - not-present page<br /> [ 547.141689] PGD 124757067 P4D 0<br /> [ 547.148842] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 547.158504] CPU: 49 PID: 8167 Comm: cat Tainted: G OE 6.8.0-38-generic #38-Ubuntu<br /> [ 547.177998] Hardware name: Supermicro AS -8126GS-TNMR/H14DSG-OD, BIOS 1.7 09/12/2025<br /> [ 547.195178] RIP: 0010:amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu]<br /> [ 547.210375] Code: e8 63 78 82 c0 45 31 d2 45 3b 75 08 48 8b 45 a0 73 44 44 89 f1 48 8b 7d 88 48 89 ca 48 c1 e2 05 48 29 ca 49 8b 4d 00 48 01 d1 83 79 10 00 74 17 49 63 f2 48 8b 49 08 41 83 c2 01 48 8d 34 76<br /> [ 547.252045] RSP: 0018:ffa0000067287ac0 EFLAGS: 00010246<br /> [ 547.263636] RAX: ff11000167c28130 RBX: ff11000127600000 RCX: 0000000000000000<br /> [ 547.279467] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ff11000125b1c800<br /> [ 547.295298] RBP: ffa0000067287b50 R08: 0000000000000000 R09: 0000000000000000<br /> [ 547.311129] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> [ 547.326959] R13: ff11000217b1de00 R14: 0000000000000000 R15: 0000000000000092<br /> [ 547.342790] FS: 0000746e59d14740(0000) GS:ff11017dfda80000(0000) knlGS:0000000000000000<br /> [ 547.360744] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 547.373489] CR2: 0000000000000010 CR3: 000000019585e001 CR4: 0000000000f71ef0<br /> [ 547.389321] PKRU: 55555554<br /> [ 547.395316] Call Trace:<br /> [ 547.400737] <br /> [ 547.405386] ? show_regs+0x6d/0x80<br /> [ 547.412929] ? __die+0x24/0x80<br /> [ 547.419697] ? page_fault_oops+0x99/0x1b0<br /> [ 547.428588] ? do_user_addr_fault+0x2ee/0x6b0<br /> [ 547.438249] ? exc_page_fault+0x83/0x1b0<br /> [ 547.446949] ? asm_exc_page_fault+0x27/0x30<br /> [ 547.456225] ? amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu]<br /> [ 547.470040] ? mas_wr_modify+0xcd/0x140<br /> [ 547.478548] sysfs_kf_bin_read+0x63/0xb0<br /> [ 547.487248] kernfs_file_read_iter+0xa1/0x190<br /> [ 547.496909] kernfs_fop_read_iter+0x25/0x40<br /> [ 547.506182] vfs_read+0x255/0x390<br /> <br /> This also result in space left assigned to negative values.<br /> Moving data alloc call before bad page check resolves both the issue.