Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix null-ptr-deref in unix_stream_sendpage().<br /> <br /> Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage()<br /> with detailed analysis and a nice repro.<br /> <br /> unix_stream_sendpage() tries to add data to the last skb in the peer&amp;#39;s<br /> recv queue without locking the queue.<br /> <br /> If the peer&amp;#39;s FD is passed to another socket and the socket&amp;#39;s FD is<br /> passed to the peer, there is a loop between them. If we close both<br /> sockets without receiving FD, the sockets will be cleaned up by garbage<br /> collection.<br /> <br /> The garbage collection iterates such sockets and unlinks skb with<br /> FD from the socket&amp;#39;s receive queue under the queue&amp;#39;s lock.<br /> <br /> So, there is a race where unix_stream_sendpage() could access an skb<br /> locklessly that is being released by garbage collection, resulting in<br /> use-after-free.<br /> <br /> To avoid the issue, unix_stream_sendpage() must lock the peer&amp;#39;s recv<br /> queue.<br /> <br /> Note the issue does not exist in 6.5+ thanks to the recent sendpage()<br /> refactoring.<br /> <br /> This patch is originally written by Linus Torvalds.<br /> <br /> BUG: unable to handle page fault for address: ffff988004dd6870<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> PREEMPT SMP PTI<br /> CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0<br /> Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44<br /> RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246<br /> RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284<br /> RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0<br /> RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00<br /> R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8<br /> FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x1a/0x1f<br /> ? page_fault_oops+0xa9/0x1e0<br /> ? fixup_exception+0x1d/0x310<br /> ? exc_page_fault+0xa8/0x150<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? kmem_cache_alloc_node+0xa2/0x1e0<br /> ? __alloc_skb+0x16c/0x1e0<br /> __alloc_skb+0x16c/0x1e0<br /> alloc_skb_with_frags+0x48/0x1e0<br /> sock_alloc_send_pskb+0x234/0x270<br /> unix_stream_sendmsg+0x1f5/0x690<br /> sock_sendmsg+0x5d/0x60<br /> ____sys_sendmsg+0x210/0x260<br /> ___sys_sendmsg+0x83/0xd0<br /> ? kmem_cache_alloc+0xc6/0x1c0<br /> ? avc_disable+0x20/0x20<br /> ? percpu_counter_add_batch+0x53/0xc0<br /> ? alloc_empty_file+0x5d/0xb0<br /> ? alloc_file+0x91/0x170<br /> ? alloc_file_pseudo+0x94/0x100<br /> ? __fget_light+0x9f/0x120<br /> __sys_sendmsg+0x54/0xa0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x69/0xd3<br /> RIP: 0033:0x7f174d639a7d<br /> Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48<br /> RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d<br /> RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007<br /> RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff<br /> R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28<br /> R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000<br />

Exposure of Sensitive System Information to an Unauthorized Control Sphere vulnerability in 10up Eight Day Week Print Workflow eight-day-week-print-workflow allows Retrieve Embedded Sensitive Data.This issue affects Eight Day Week Print Workflow: from n/a through

Cross-Site Request Forgery (CSRF) vulnerability in titopandub Evergreen Post Tweeter evergreen-post-tweeter allows Stored XSS.This issue affects Evergreen Post Tweeter: from n/a through

Server-Side Request Forgery (SSRF) vulnerability in 6Storage 6Storage Rentals 6storage-rentals allows Server Side Request Forgery.This issue affects 6Storage Rentals: from n/a through

Cross-Site Request Forgery (CSRF) vulnerability in tmtraderunner Trade Runner traderunner allows Cross Site Request Forgery.This issue affects Trade Runner: from n/a through

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in TouchOfTech Draft Notify draft-notify allows Stored XSS.This issue affects Draft Notify: from n/a through

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in AMP-MODE Review Disclaimer review-disclaimer allows Stored XSS.This issue affects Review Disclaimer: from n/a through

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Fix an out of bounds error in BIOS parser<br /> <br /> The array is hardcoded to 8 in atomfirmware.h, but firmware provides<br /> a bigger one sometimes. Deferencing the larger array causes an out<br /> of bounds error.<br /> <br /> commit 4fc1ba4aa589 ("drm/amd/display: fix array index out of bound error<br /> in bios parser") fixed some of this, but there are two other cases<br /> not covered by it. Fix those as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: Fix system crash due to lack of free space in LFS<br /> <br /> When f2fs tries to checkpoint during foreground gc in LFS mode, system<br /> crash occurs due to lack of free space if the amount of dirty node and<br /> dentry pages generated by data migration exceeds free space.<br /> The reproduction sequence is as follows.<br /> <br /> - 20GiB capacity block device (null_blk)<br /> - format and mount with LFS mode<br /> - create a file and write 20,000MiB<br /> - 4k random write on full range of the file<br /> <br /> RIP: 0010:new_curseg+0x48a/0x510 [f2fs]<br /> Code: 55 e7 f5 89 c0 48 0f af c3 48 8b 5d c0 48 c1 e8 20 83 c0 01 89 43 6c 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0b f0 41 80 4f 48 04 45 85 f6 0f 84 ba fd ff ff e9 ef fe ff ff<br /> RSP: 0018:ffff977bc397b218 EFLAGS: 00010246<br /> RAX: 00000000000027b9 RBX: 0000000000000000 RCX: 00000000000027c0<br /> RDX: 0000000000000000 RSI: 00000000000027b9 RDI: ffff8c25ab4e74f8<br /> RBP: ffff977bc397b268 R08: 00000000000027b9 R09: ffff8c29e4a34b40<br /> R10: 0000000000000001 R11: ffff977bc397b0d8 R12: 0000000000000000<br /> R13: ffff8c25b4dd81a0 R14: 0000000000000000 R15: ffff8c2f667f9000<br /> FS: 0000000000000000(0000) GS:ffff8c344ec80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000c00055d000 CR3: 0000000e30810003 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> allocate_segment_by_default+0x9c/0x110 [f2fs]<br /> f2fs_allocate_data_block+0x243/0xa30 [f2fs]<br /> ? __mod_lruvec_page_state+0xa0/0x150<br /> do_write_page+0x80/0x160 [f2fs]<br /> f2fs_do_write_node_page+0x32/0x50 [f2fs]<br /> __write_node_page+0x339/0x730 [f2fs]<br /> f2fs_sync_node_pages+0x5a6/0x780 [f2fs]<br /> block_operations+0x257/0x340 [f2fs]<br /> f2fs_write_checkpoint+0x102/0x1050 [f2fs]<br /> f2fs_gc+0x27c/0x630 [f2fs]<br /> ? folio_mark_dirty+0x36/0x70<br /> f2fs_balance_fs+0x16f/0x180 [f2fs]<br /> <br /> This patch adds checking whether free sections are enough before checkpoint<br /> during gc.<br /> <br /> [Jaegeuk Kim: code clean-up]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: prevent deadlock by moving j1939_sk_errqueue()<br /> <br /> This commit addresses a deadlock situation that can occur in certain<br /> scenarios, such as when running data TP/ETP transfer and subscribing to<br /> the error queue while receiving a net down event. The deadlock involves<br /> locks in the following order:<br /> <br /> 3<br /> j1939_session_list_lock -&gt; active_session_list_lock<br /> j1939_session_activate<br /> ...<br /> j1939_sk_queue_activate_next -&gt; sk_session_queue_lock<br /> ...<br /> j1939_xtp_rx_eoma_one<br /> <br /> 2<br /> j1939_sk_queue_drop_all -&gt; sk_session_queue_lock<br /> ...<br /> j1939_sk_netdev_event_netdown -&gt; j1939_socks_lock<br /> j1939_netdev_notify<br /> <br /> 1<br /> j1939_sk_errqueue -&gt; j1939_socks_lock<br /> __j1939_session_cancel -&gt; active_session_list_lock<br /> j1939_tp_rxtimer<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;priv-&gt;active_session_list_lock);<br /> lock(&amp;jsk-&gt;sk_session_queue_lock);<br /> lock(&amp;priv-&gt;active_session_list_lock);<br /> lock(&amp;priv-&gt;j1939_socks_lock);<br /> <br /> The solution implemented in this commit is to move the<br /> j1939_sk_errqueue() call out of the active_session_list_lock context,<br /> thus preventing the deadlock situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: turn quotas off if mount failed after enabling quotas<br /> <br /> Yi found during a review of the patch "ext4: don&amp;#39;t BUG on inconsistent<br /> journal feature" that when ext4_mark_recovery_complete() returns an error<br /> value, the error handling path does not turn off the enabled quotas,<br /> which triggers the following kmemleak:<br /> <br /> ================================================================<br /> unreferenced object 0xffff8cf68678e7c0 (size 64):<br /> comm "mount", pid 746, jiffies 4294871231 (age 11.540s)<br /> hex dump (first 32 bytes):<br /> 00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ............A...<br /> c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ............H...<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x4d4/0x880<br /> [] kmalloc_trace+0x39/0x140<br /> [] v2_read_file_info+0x18a/0x3a0<br /> [] dquot_load_quota_sb+0x2ed/0x770<br /> [] dquot_load_quota_inode+0xc6/0x1c0<br /> [] ext4_enable_quotas+0x17e/0x3a0 [ext4]<br /> [] __ext4_fill_super+0x3448/0x3910 [ext4]<br /> [] ext4_fill_super+0x13d/0x340 [ext4]<br /> [] get_tree_bdev+0x1dc/0x370<br /> [] ext4_get_tree+0x1d/0x30 [ext4]<br /> [] vfs_get_tree+0x31/0x160<br /> [] do_new_mount+0x1d5/0x480<br /> [] path_mount+0x22e/0xbe0<br /> [] do_mount+0x95/0xc0<br /> [] __x64_sys_mount+0xc4/0x160<br /> [] do_syscall_64+0x3f/0x90<br /> ================================================================<br /> <br /> To solve this problem, we add a "failed_mount10" tag, and call<br /> ext4_quota_off_umount() in this tag to release the enabled qoutas.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: core: Fix target_cmd_counter leak<br /> <br /> The target_cmd_counter struct allocated via target_alloc_cmd_counter() is<br /> never freed, resulting in leaks across various transport types, e.g.:<br /> <br /> unreferenced object 0xffff88801f920120 (size 96):<br /> comm "sh", pid 102, jiffies 4294892535 (age 713.412s)<br /> hex dump (first 32 bytes):<br /> 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 38 01 92 1f 80 88 ff ff ........8.......<br /> backtrace:<br /> [] kmalloc_trace+0x11/0x20<br /> [] target_alloc_cmd_counter+0x17/0x90 [target_core_mod]<br /> [] target_setup_session+0x2d/0x140 [target_core_mod]<br /> [] tcm_loop_tpg_nexus_store+0x19b/0x350 [tcm_loop]<br /> [] configfs_write_iter+0xb1/0x120<br /> [] vfs_write+0x2e4/0x3c0<br /> [] ksys_write+0x80/0xb0<br /> [] do_syscall_64+0x42/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Free the structure alongside the corresponding iscsit_conn / se_sess<br /> parent.