Vulnerabilities

IBM Sterling Secure Proxy 6.0.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.1.0.0, and 6.2.0.0 could allow an unauthorized attacker to retrieve or alter sensitive information contents due to incorrect permission assignments.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm array: fix releasing a faulty array block twice in dm_array_cursor_end<br /> <br /> When dm_bm_read_lock() fails due to locking or checksum errors, it<br /> releases the faulty block implicitly while leaving an invalid output<br /> pointer behind. The caller of dm_bm_read_lock() should not operate on<br /> this invalid dm_block pointer, or it will lead to undefined result.<br /> For example, the dm_array_cursor incorrectly caches the invalid pointer<br /> on reading a faulty array block, causing a double release in<br /> dm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().<br /> <br /> Reproduce steps:<br /> <br /> 1. initialize a cache device<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc $262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> 2. wipe the second array block offline<br /> <br /> dmsteup remove cache cmeta cdata corig<br /> mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \<br /> 2&gt;/dev/null | hexdump -e &amp;#39;1/8 "%u\n"&amp;#39;)<br /> ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \<br /> 2&gt;/dev/null | hexdump -e &amp;#39;1/8 "%u\n"&amp;#39;)<br /> dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock<br /> <br /> 3. try reopen the cache device<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc $262144"<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> Kernel logs:<br /> <br /> (snip)<br /> device-mapper: array: array_block_check failed: blocknr 0 != wanted 10<br /> device-mapper: block manager: array validator check failed for block 10<br /> device-mapper: array: get_ablock failed<br /> device-mapper: cache metadata: dm_array_cursor_next for mapping failed<br /> ------------[ cut here ]------------<br /> kernel BUG at drivers/md/dm-bufio.c:638!<br /> <br /> Fix by setting the cached block pointer to NULL on errors.<br /> <br /> In addition to the reproducer described above, this fix can be<br /> verified using the "array_cursor/damaged" test in dm-unit:<br /> dm-unit run /pdata/array_cursor/damaged --kernel-dir

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix divide error in DM plane scale calcs<br /> <br /> dm_get_plane_scale doesn&amp;#39;t take into account plane scaled size equal to<br /> zero, leading to a kernel oops due to division by zero. Fix by setting<br /> out-scale size as zero when the dst size is zero, similar to what is<br /> done by drm_calc_scale(). This issue started with the introduction of<br /> cursor ovelay mode that uses this function to assess cursor mode changes<br /> via dm_crtc_get_cursor_mode() before checking plane state.<br /> <br /> [Dec17 17:14] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> [ +0.000018] CPU: 5 PID: 1660 Comm: surface-DP-1 Not tainted 6.10.0+ #231<br /> [ +0.000007] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024<br /> [ +0.000004] RIP: 0010:dm_get_plane_scale+0x3f/0x60 [amdgpu]<br /> [ +0.000553] Code: 44 0f b7 41 3a 44 0f b7 49 3e 83 e0 0f 48 0f a3 c2 73 21 69 41 28 e8 03 00 00 31 d2 41 f7 f1 31 d2 89 06 69 41 2c e8 03 00 00 f7 f0 89 07 e9 d7 d8 7e e9 44 89 c8 45 89 c1 41 89 c0 eb d4 66<br /> [ +0.000005] RSP: 0018:ffffa8df0de6b8a0 EFLAGS: 00010246<br /> [ +0.000006] RAX: 00000000000003e8 RBX: ffff9ac65c1f6e00 RCX: ffff9ac65d055500<br /> [ +0.000003] RDX: 0000000000000000 RSI: ffffa8df0de6b8b0 RDI: ffffa8df0de6b8b4<br /> [ +0.000004] RBP: ffff9ac64e7a5800 R08: 0000000000000000 R09: 0000000000000a00<br /> [ +0.000003] R10: 00000000000000ff R11: 0000000000000054 R12: ffff9ac6d0700010<br /> [ +0.000003] R13: ffff9ac65d054f00 R14: ffff9ac65d055500 R15: ffff9ac64e7a60a0<br /> [ +0.000004] FS: 00007f869ea00640(0000) GS:ffff9ac970080000(0000) knlGS:0000000000000000<br /> [ +0.000004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000003] CR2: 000055ca701becd0 CR3: 000000010e7f2000 CR4: 0000000000350ef0<br /> [ +0.000004] Call Trace:<br /> [ +0.000007] <br /> [ +0.000006] ? __die_body.cold+0x19/0x27<br /> [ +0.000009] ? die+0x2e/0x50<br /> [ +0.000007] ? do_trap+0xca/0x110<br /> [ +0.000007] ? do_error_trap+0x6a/0x90<br /> [ +0.000006] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]<br /> [ +0.000504] ? exc_divide_error+0x38/0x50<br /> [ +0.000005] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]<br /> [ +0.000488] ? asm_exc_divide_error+0x1a/0x20<br /> [ +0.000011] ? dm_get_plane_scale+0x3f/0x60 [amdgpu]<br /> [ +0.000593] dm_crtc_get_cursor_mode+0x33f/0x430 [amdgpu]<br /> [ +0.000562] amdgpu_dm_atomic_check+0x2ef/0x1770 [amdgpu]<br /> [ +0.000501] drm_atomic_check_only+0x5e1/0xa30 [drm]<br /> [ +0.000047] drm_mode_atomic_ioctl+0x832/0xcb0 [drm]<br /> [ +0.000050] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm]<br /> [ +0.000047] drm_ioctl_kernel+0xb3/0x100 [drm]<br /> [ +0.000062] drm_ioctl+0x27a/0x4f0 [drm]<br /> [ +0.000049] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm]<br /> [ +0.000055] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]<br /> [ +0.000360] __x64_sys_ioctl+0x97/0xd0<br /> [ +0.000010] do_syscall_64+0x82/0x190<br /> [ +0.000008] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm]<br /> [ +0.000044] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000006] ? drm_ioctl_kernel+0xb3/0x100 [drm]<br /> [ +0.000040] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? __check_object_size+0x50/0x220<br /> [ +0.000007] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? drm_ioctl+0x2a4/0x4f0 [drm]<br /> [ +0.000039] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm]<br /> [ +0.000043] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? __pm_runtime_suspend+0x69/0xc0<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? amdgpu_drm_ioctl+0x71/0x90 [amdgpu]<br /> [ +0.000366] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000006] ? syscall_exit_to_user_mode+0x77/0x210<br /> [ +0.000007] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? do_syscall_64+0x8e/0x190<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000006] ? do_syscall_64+0x8e/0x190<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ +0.000008] RIP: 0033:0x55bb7cd962bc<br /> [ +0.000007] Code: 4c 89 6c 24 18 4c 89 64 24 20 4c 89 74 24 28 0f 57 c0 0f 11 44 24 30 89 c7 48 8d 54 24 08 b8 10 00 00 00 be bc 64<br /> ---truncated---

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 /> drm/amdgpu: Add a lock when accessing the buddy trim function<br /> <br /> When running YouTube videos and Steam games simultaneously,<br /> the tester found a system hang / race condition issue with<br /> the multi-display configuration setting. Adding a lock to<br /> the buddy allocator&amp;#39;s trim function would be the solution.<br /> <br /> <br /> [ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108<br /> [ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy]<br /> [ 7197.250470] Call Trace:<br /> [ 7197.250472] <br /> [ 7197.250475] ? show_regs+0x6d/0x80<br /> [ 7197.250481] ? die_addr+0x37/0xa0<br /> [ 7197.250483] ? exc_general_protection+0x1db/0x480<br /> [ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper]<br /> [ 7197.250493] ? asm_exc_general_protection+0x27/0x30<br /> [ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy]<br /> [ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy]<br /> [ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy]<br /> [ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu]<br /> [ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm]<br /> [ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm]<br /> [ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm]<br /> [ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu]<br /> [ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu]<br /> [ 7197.251025] ? try_wait_for_completion+0x59/0x70<br /> [ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0<br /> [ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70<br /> [ 7197.251037] drm_atomic_helper_commit+0x84/0x160<br /> [ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70<br /> [ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850<br /> [ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> [ 7197.251049] drm_ioctl_kernel+0xb9/0x120<br /> [ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 7197.251056] drm_ioctl+0x2d4/0x550<br /> [ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> [ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]<br /> [ 7197.251186] __x64_sys_ioctl+0xa0/0xf0<br /> [ 7197.251190] x64_sys_call+0x143b/0x25c0<br /> [ 7197.251193] do_syscall_64+0x7f/0x180<br /> [ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu]<br /> [ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0<br /> [ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5<br /> <br /> (cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zlib: fix avail_in bytes for s390 zlib HW compression path<br /> <br /> Since the input data length passed to zlib_compress_folios() can be<br /> arbitrary, always setting strm.avail_in to a multiple of PAGE_SIZE may<br /> cause read-in bytes to exceed the input range. Currently this triggers<br /> an assert in btrfs_compress_folios() on the debug kernel (see below).<br /> Fix strm.avail_in calculation for S390 hardware acceleration path.<br /> <br /> assertion failed: *total_in 0000021761df6538: 0707 bcr 0,%r7<br /> 0000021761df653a: 0707 bcr 0,%r7<br /> 0000021761df653c: 0707 bcr 0,%r7<br /> 0000021761df653e: 0707 bcr 0,%r7<br /> 0000021761df6540: c004004bb7ec brcl 0,000002176276d518<br /> Call Trace:<br /> [] btrfs_compress_folios+0x198/0x1a0<br /> ([] btrfs_compress_folios+0x194/0x1a0)<br /> [] compress_file_range+0x3b8/0x6d0<br /> [] btrfs_work_helper+0x10c/0x160<br /> [] process_one_work+0x2b0/0x5d0<br /> [] worker_thread+0x20e/0x3e0<br /> [] kthread+0x15a/0x170<br /> [] __ret_from_fork+0x3c/0x60<br /> [] ret_from_fork+0xa/0x38<br /> INFO: lockdep is turned off.<br /> Last Breaking-Event-Address:<br /> [] _printk+0x4c/0x58<br /> Kernel panic - not syncing: Fatal exception: panic_on_oops

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Set private-&gt;all_drm_private[i]-&gt;drm to NULL if mtk_drm_bind returns err<br /> <br /> The pointer need to be set to NULL, otherwise KASAN complains about<br /> use-after-free. Because in mtk_drm_bind, all private&amp;#39;s drm are set<br /> as follows.<br /> <br /> private-&gt;all_drm_private[i]-&gt;drm = drm;<br /> <br /> And drm will be released by drm_dev_put in case mtk_drm_kms_init returns<br /> failure. However, the shutdown path still accesses the previous allocated<br /> memory in drm_atomic_helper_shutdown.<br /> <br /> [ 84.874820] watchdog: watchdog0: watchdog did not stop!<br /> [ 86.512054] ==================================================================<br /> [ 86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378<br /> [ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1<br /> [ 86.515213]<br /> [ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55<br /> [ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022<br /> [ 86.517960] Call trace:<br /> [ 86.518333] show_stack+0x20/0x38 (C)<br /> [ 86.518891] dump_stack_lvl+0x90/0xd0<br /> [ 86.519443] print_report+0xf8/0x5b0<br /> [ 86.519985] kasan_report+0xb4/0x100<br /> [ 86.520526] __asan_report_load8_noabort+0x20/0x30<br /> [ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378<br /> [ 86.521966] mtk_drm_shutdown+0x54/0x80<br /> [ 86.522546] platform_shutdown+0x64/0x90<br /> [ 86.523137] device_shutdown+0x260/0x5b8<br /> [ 86.523728] kernel_restart+0x78/0xf0<br /> [ 86.524282] __do_sys_reboot+0x258/0x2f0<br /> [ 86.524871] __arm64_sys_reboot+0x90/0xd8<br /> [ 86.525473] invoke_syscall+0x74/0x268<br /> [ 86.526041] el0_svc_common.constprop.0+0xb0/0x240<br /> [ 86.526751] do_el0_svc+0x4c/0x70<br /> [ 86.527251] el0_svc+0x4c/0xc0<br /> [ 86.527719] el0t_64_sync_handler+0x144/0x168<br /> [ 86.528367] el0t_64_sync+0x198/0x1a0<br /> [ 86.528920]<br /> [ 86.529157] The buggy address belongs to the physical page:<br /> [ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc<br /> [ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff)<br /> [ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000<br /> [ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 86.534511] page dumped because: kasan: bad access detected<br /> [ 86.535323]<br /> [ 86.535559] Memory state around the buggy address:<br /> [ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 86.538363] &gt;ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 86.544733] ^<br /> [ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 86.563928] ==================================================================<br /> [ 86.571093] Disabling lock debugging due to kernel taint<br /> [ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b<br /> [ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f]<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: Fix oops in nfs_netfs_init_request() when copying to cache<br /> <br /> When netfslib wants to copy some data that has just been read on behalf of<br /> nfs, it creates a new write request and calls nfs_netfs_init_request() to<br /> initialise it, but with a NULL file pointer. This causes<br /> nfs_file_open_context() to oops - however, we don&amp;#39;t actually need the nfs<br /> context as we&amp;#39;re only going to write to the cache.<br /> <br /> Fix this by just returning if we aren&amp;#39;t given a file pointer and emit a<br /> warning if the request was for something other than copy-to-cache.<br /> <br /> Further, fix nfs_netfs_free_request() so that it doesn&amp;#39;t try to free the<br /> context if the pointer is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix enomem handling in buffered reads<br /> <br /> If netfs_read_to_pagecache() gets an error from either -&gt;prepare_read() or<br /> from netfs_prepare_read_iterator(), it needs to decrement -&gt;nr_outstanding,<br /> cancel the subrequest and break out of the issuing loop. Currently, it<br /> only does this for two of the cases, but there are two more that aren&amp;#39;t<br /> handled.<br /> <br /> Fix this by moving the handling to a common place and jumping to it from<br /> all four places. This is in preference to inserting a wrapper around<br /> netfs_prepare_read_iterator() as proposed by Dmitry Antipov[1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: relax assertions on failure to encode file handles<br /> <br /> Encoding file handles is usually performed by a filesystem &gt;encode_fh()<br /> method that may fail for various reasons.<br /> <br /> The legacy users of exportfs_encode_fh(), namely, nfsd and<br /> name_to_handle_at(2) syscall are ready to cope with the possibility<br /> of failure to encode a file handle.<br /> <br /> There are a few other users of exportfs_encode_{fh,fid}() that<br /> currently have a WARN_ON() assertion when -&gt;encode_fh() fails.<br /> Relax those assertions because they are wrong.<br /> <br /> The second linked bug report states commit 16aac5ad1fa9 ("ovl: support<br /> encoding non-decodable file handles") in v6.6 as the regressing commit,<br /> but this is not accurate.<br /> <br /> The aforementioned commit only increases the chances of the assertion<br /> and allows triggering the assertion with the reproducer using overlayfs,<br /> inotify and drop_caches.<br /> <br /> Triggering this assertion was always possible with other filesystems and<br /> other reasons of -&gt;encode_fh() failures and more particularly, it was<br /> also possible with the exact same reproducer using overlayfs that is<br /> mounted with options index=on,nfs_export=on also on kernels

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add check for granularity in dml ceil/floor helpers<br /> <br /> [Why]<br /> Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()<br /> should check for granularity is non zero to avoid assert and<br /> divide-by-zero error in dcn_bw_ functions.<br /> <br /> [How]<br /> Add check for granularity 0.<br /> <br /> (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix a missing return value check bug<br /> <br /> In the smb2_send_interim_resp(), if ksmbd_alloc_work_struct()<br /> fails to allocate a node, it returns a NULL pointer to the<br /> in_work pointer. This can lead to an illegal memory write of<br /> in_work-&gt;response_buf when allocate_interim_rsp_buf() attempts<br /> to perform a kzalloc() on it.<br /> <br /> To address this issue, incorporating a check for the return<br /> value of ksmbd_alloc_work_struct() ensures that the function<br /> returns immediately upon allocation failure, thereby preventing<br /> the aforementioned illegal memory access.