Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> llc: call sock_orphan() at release time<br /> <br /> syzbot reported an interesting trace [1] caused by a stale sk-&gt;sk_wq<br /> pointer in a closed llc socket.<br /> <br /> In commit ff7b11aa481f ("net: socket: set sock-&gt;sk to NULL after<br /> calling proto_ops::release()") Eric Biggers hinted that some protocols<br /> are missing a sock_orphan(), we need to perform a full audit.<br /> <br /> In net-next, I plan to clear sock-&gt;sk from sock_orphan() and<br /> amend Eric patch to add a warning.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]<br /> BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]<br /> BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]<br /> BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468<br /> Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27<br /> <br /> CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc4/0x620 mm/kasan/report.c:488<br /> kasan_report+0xda/0x110 mm/kasan/report.c:601<br /> list_empty include/linux/list.h:373 [inline]<br /> waitqueue_active include/linux/wait.h:127 [inline]<br /> sock_def_write_space_wfree net/core/sock.c:3384 [inline]<br /> sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468<br /> skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080<br /> skb_release_all net/core/skbuff.c:1092 [inline]<br /> napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404<br /> e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970<br /> e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]<br /> e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801<br /> __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576<br /> napi_poll net/core/dev.c:6645 [inline]<br /> net_rx_action+0x956/0xe90 net/core/dev.c:6778<br /> __do_softirq+0x21a/0x8de kernel/softirq.c:553<br /> run_ksoftirqd kernel/softirq.c:921 [inline]<br /> run_ksoftirqd+0x31/0x60 kernel/softirq.c:913<br /> smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164<br /> kthread+0x2c6/0x3a0 kernel/kthread.c:388<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242<br /> <br /> <br /> Allocated by task 5167:<br /> kasan_save_stack+0x33/0x50 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> unpoison_slab_object mm/kasan/common.c:314 [inline]<br /> __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook mm/slub.c:3813 [inline]<br /> slab_alloc_node mm/slub.c:3860 [inline]<br /> kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879<br /> alloc_inode_sb include/linux/fs.h:3019 [inline]<br /> sock_alloc_inode+0x25/0x1c0 net/socket.c:308<br /> alloc_inode+0x5d/0x220 fs/inode.c:260<br /> new_inode_pseudo+0x16/0x80 fs/inode.c:1005<br /> sock_alloc+0x40/0x270 net/socket.c:634<br /> __sock_create+0xbc/0x800 net/socket.c:1535<br /> sock_create net/socket.c:1622 [inline]<br /> __sys_socket_create net/socket.c:1659 [inline]<br /> __sys_socket+0x14c/0x260 net/socket.c:1706<br /> __do_sys_socket net/socket.c:1720 [inline]<br /> __se_sys_socket net/socket.c:1718 [inline]<br /> __x64_sys_socket+0x72/0xb0 net/socket.c:1718<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Freed by task 0:<br /> kasan_save_stack+0x33/0x50 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640<br /> poison_slab_object mm/kasan/common.c:241 [inline]<br /> __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2121 [inlin<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmr: fix kernel panic when forwarding mcast packets<br /> <br /> The stacktrace was:<br /> [ 86.305548] BUG: kernel NULL pointer dereference, address: 0000000000000092<br /> [ 86.306815] #PF: supervisor read access in kernel mode<br /> [ 86.307717] #PF: error_code(0x0000) - not-present page<br /> [ 86.308624] PGD 0 P4D 0<br /> [ 86.309091] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 86.309883] CPU: 2 PID: 3139 Comm: pimd Tainted: G U 6.8.0-6wind-knet #1<br /> [ 86.311027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014<br /> [ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)<br /> [ 86.313399] Code: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe b8 92 00 00 00 00 0f 84 55 ff ff ff 49 83 47 38 01 45 85 e4 0f<br /> [ 86.316565] RSP: 0018:ffffad21c0583ae0 EFLAGS: 00010246<br /> [ 86.317497] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 86.318596] RDX: ffff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 86.319627] RBP: ffffad21c0583b30 R08: 0000000000000000 R09: 0000000000000000<br /> [ 86.320650] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> [ 86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80<br /> [ 86.322873] FS: 00007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000<br /> [ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0<br /> [ 86.326589] Call Trace:<br /> [ 86.327036] <br /> [ 86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479)<br /> [ 86.328049] ? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434)<br /> [ 86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707)<br /> [ 86.329107] ? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264)<br /> [ 86.329756] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.330350] ? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminator 1))<br /> [ 86.331013] ? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch/x86/mm/fault.c:1563)<br /> [ 86.331702] ? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570)<br /> [ 86.332468] ? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)<br /> [ 86.333183] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet/net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273)<br /> [ 86.334583] ? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363)<br /> [ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)<br /> [ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.336854] ? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)<br /> [ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944)<br /> [ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862)<br /> [ 86.339232] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)<br /> [ 86.339809] ? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181)<br /> [ 86.340342] ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:1415)<br /> [ 86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836)<br /> [ 86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminator 13))<br /> [ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716)<br /> [ 86.342747] do_sock_setsockopt (/build/work/knet/net/socket.c:2313)<br /> [ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/kn<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler<br /> <br /> Inside scsi_eh_wakeup(), scsi_host_busy() is called &amp; checked with host<br /> lock every time for deciding if error handler kthread needs to be waken up.<br /> <br /> This can be too heavy in case of recovery, such as:<br /> <br /> - N hardware queues<br /> <br /> - queue depth is M for each hardware queue<br /> <br /> - each scsi_host_busy() iterates over (N * M) tag/requests<br /> <br /> If recovery is triggered in case that all requests are in-flight, each<br /> scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called<br /> for the last in-flight request, scsi_host_busy() has been run for (N * M -<br /> 1) times, and request has been iterated for (N*M - 1) * (N * M) times.<br /> <br /> If both N and M are big enough, hard lockup can be triggered on acquiring<br /> host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).<br /> <br /> Fix the issue by calling scsi_host_busy() outside the host lock. We don&amp;#39;t<br /> need the host lock for getting busy count because host the lock never<br /> covers that.<br /> <br /> [mkp: Drop unnecessary &amp;#39;busy&amp;#39; variables pointed out by Bart]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> UBSAN: array-index-out-of-bounds in dtSplitRoot<br /> <br /> Syzkaller reported the following issue:<br /> <br /> oop0: detected capacity change from 0 to 32768<br /> <br /> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9<br /> index -2 is out of range for type &amp;#39;struct dtslot [128]&amp;#39;<br /> CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106<br /> ubsan_epilogue lib/ubsan.c:151 [inline]<br /> __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283<br /> dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971<br /> dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]<br /> dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863<br /> jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270<br /> vfs_mkdir+0x3b3/0x590 fs/namei.c:4013<br /> do_mkdirat+0x279/0x550 fs/namei.c:4038<br /> __do_sys_mkdirat fs/namei.c:4053 [inline]<br /> __se_sys_mkdirat fs/namei.c:4051 [inline]<br /> __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051<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 /> RIP: 0033:0x7fcdc0113fd9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9<br /> RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003<br /> RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0<br /> R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000<br /> R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000<br /> <br /> <br /> The issue is caused when the value of fsi becomes less than -1.<br /> The check to break the loop when fsi value becomes -1 is present<br /> but syzbot was able to produce value less than -1 which cause the error.<br /> This patch simply add the change for the values less than 0.<br /> <br /> The patch is tested via syzbot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree<br /> <br /> Syzkaller reported the following issue:<br /> <br /> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6<br /> index 196694 is out of range for type &amp;#39;s8[1365]&amp;#39; (aka &amp;#39;signed char[1365]&amp;#39;)<br /> CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106<br /> ubsan_epilogue lib/ubsan.c:217 [inline]<br /> __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348<br /> dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867<br /> dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834<br /> dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331<br /> dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]<br /> dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402<br /> txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534<br /> txUpdateMap+0x342/0x9e0<br /> txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]<br /> jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732<br /> kthread+0x2d3/0x370 kernel/kthread.c:388<br /> ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304<br /> <br /> ================================================================================<br /> Kernel panic - not syncing: UBSAN: panic_on_warn set ...<br /> CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106<br /> panic+0x30f/0x770 kernel/panic.c:340<br /> check_panic_on_warn+0x82/0xa0 kernel/panic.c:236<br /> ubsan_epilogue lib/ubsan.c:223 [inline]<br /> __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348<br /> dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867<br /> dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834<br /> dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331<br /> dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]<br /> dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402<br /> txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534<br /> txUpdateMap+0x342/0x9e0<br /> txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]<br /> jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732<br /> kthread+0x2d3/0x370 kernel/kthread.c:388<br /> ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304<br /> <br /> Kernel Offset: disabled<br /> Rebooting in 86400 seconds..<br /> <br /> The issue is caused when the value of lp becomes greater than<br /> CTLTREESIZE which is the max size of stree. Adding a simple check<br /> solves this issue.<br /> <br /> Dave:<br /> As the function returns a void, good error handling<br /> would require a more intrusive code reorganization, so I modified<br /> Osama&amp;#39;s patch at use WARN_ON_ONCE for lack of a cleaner option.<br /> <br /> The patch is tested via syzbot.

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 /> powerpc/lib: Validate size for vector operations<br /> <br /> Some of the fp/vmx code in sstep.c assume a certain maximum size for the<br /> instructions being emulated. The size of those operations however is<br /> determined separately in analyse_instr().<br /> <br /> Add a check to validate the assumption on the maximum size of the<br /> operations, so as to prevent any unintended kernel stack corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/mm: Fix null-pointer dereference in pgtable_cache_add<br /> <br /> kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in diNewExt<br /> <br /> [Syz report]<br /> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2<br /> index -878706688 is out of range for type &amp;#39;struct iagctl[128]&amp;#39;<br /> CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106<br /> ubsan_epilogue lib/ubsan.c:217 [inline]<br /> __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348<br /> diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360<br /> diAllocExt fs/jfs/jfs_imap.c:1949 [inline]<br /> diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666<br /> diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587<br /> ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56<br /> jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225<br /> vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106<br /> do_mkdirat+0x264/0x3a0 fs/namei.c:4129<br /> __do_sys_mkdir fs/namei.c:4149 [inline]<br /> __se_sys_mkdir fs/namei.c:4147 [inline]<br /> __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> RIP: 0033:0x7fcb7e6a0b57<br /> Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053<br /> RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57<br /> RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140<br /> RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> [Analysis]<br /> When the agstart is too large, it can cause agno overflow.<br /> <br /> [Fix]<br /> After obtaining agno, if the value is invalid, exit the subsequent process.<br /> <br /> <br /> Modified the test from agno &gt; MAXAG to agno &gt;= MAXAG based on linux-next<br /> report by kernel test robot (Dan Carpenter).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix uaf in jfs_evict_inode<br /> <br /> When the execution of diMount(ipimap) fails, the object ipimap that has been<br /> released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs<br /> when rcu_core() calls jfs_free_node().<br /> <br /> Therefore, when diMount(ipimap) fails, sbi-&gt;ipimap should not be initialized as<br /> ipimap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in dbAdjTree<br /> <br /> Currently there is a bound check missing in the dbAdjTree while<br /> accessing the dmt_stree. To add the required check added the bool is_ctl<br /> which is required to determine the size as suggest in the following<br /> commit.<br /> https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix slab-out-of-bounds Read in dtSearch<br /> <br /> Currently while searching for current page in the sorted entry table<br /> of the page there is a out of bound access. Added a bound check to fix<br /> the error.<br /> <br /> Dave:<br /> Set return code to -EIO