Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd: fix potential integer overflow on shift of a int<br /> <br /> The left shift of int 32 bit integer constant 1 is evaluated using 32 bit<br /> arithmetic and then passed as a 64 bit function argument. In the case where<br /> i is 32 or more this can lead to an overflow. Avoid this by shifting<br /> using the BIT_ULL macro instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: designware: use casting of u64 in clock multiplication to avoid overflow<br /> <br /> In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow<br /> by depending on the values of the given parameters including the ic_clk.<br /> For example in our use case where ic_clk is larger than one million,<br /> multiplication of ic_clk * 4700 will result in 32 bit overflow.<br /> <br /> Add cast of u64 to the calculation to avoid multiplication overflow, and<br /> use the corresponding define for divide.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: CPPC: Add u64 casts to avoid overflowing<br /> <br /> The fields of the _CPC object are unsigned 32-bits values.<br /> To avoid overflows while using _CPC&amp;#39;s values, add &amp;#39;u64&amp;#39; casts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> w1: fix WARNING after calling w1_process()<br /> <br /> I got the following WARNING message while removing driver(ds2482):<br /> <br /> ------------[ cut here ]------------<br /> do not call blocking ops when !TASK_RUNNING; state=1 set at [] w1_process+0x9e/0x1d0 [wire]<br /> WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0<br /> CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307<br /> RIP: 0010:__might_sleep+0x98/0xa0<br /> Call Trace:<br /> exit_signals+0x6c/0x550<br /> do_exit+0x2b4/0x17e0<br /> kthread_exit+0x52/0x60<br /> kthread+0x16d/0x1e0<br /> ret_from_fork+0x1f/0x30<br /> <br /> The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(),<br /> set it to TASK_RUNNING when it breaks out of the loop to avoid the<br /> warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Always check inode size of inline inodes<br /> <br /> Check if the inode size of stuffed (inline) inodes is within the allowed<br /> range when reading inodes from disk (gfs2_dinode_in()). This prevents<br /> us from on-disk corruption.<br /> <br /> The two checks in stuffed_readpage() and gfs2_unstuffer_page() that just<br /> truncate inline data to the maximum allowed size don&amp;#39;t actually make<br /> sense, and they can be removed now as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on i_extra_isize in is_alive()<br /> <br /> syzbot found a f2fs bug:<br /> <br /> BUG: KASAN: slab-out-of-bounds in data_blkaddr fs/f2fs/f2fs.h:2891 [inline]<br /> BUG: KASAN: slab-out-of-bounds in is_alive fs/f2fs/gc.c:1117 [inline]<br /> BUG: KASAN: slab-out-of-bounds in gc_data_segment fs/f2fs/gc.c:1520 [inline]<br /> BUG: KASAN: slab-out-of-bounds in do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734<br /> Read of size 4 at addr ffff888076557568 by task kworker/u4:3/52<br /> <br /> CPU: 1 PID: 52 Comm: kworker/u4:3 Not tainted 6.1.0-rc4-syzkaller-00362-gfef7fd48922d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Workqueue: writeback wb_workfn (flush-7:0)<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x15e/0x45d mm/kasan/report.c:395<br /> kasan_report+0xbb/0x1f0 mm/kasan/report.c:495<br /> data_blkaddr fs/f2fs/f2fs.h:2891 [inline]<br /> is_alive fs/f2fs/gc.c:1117 [inline]<br /> gc_data_segment fs/f2fs/gc.c:1520 [inline]<br /> do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734<br /> f2fs_gc+0x88c/0x20a0 fs/f2fs/gc.c:1831<br /> f2fs_balance_fs+0x544/0x6b0 fs/f2fs/segment.c:410<br /> f2fs_write_inode+0x57e/0xe20 fs/f2fs/inode.c:753<br /> write_inode fs/fs-writeback.c:1440 [inline]<br /> __writeback_single_inode+0xcfc/0x1440 fs/fs-writeback.c:1652<br /> writeback_sb_inodes+0x54d/0xf90 fs/fs-writeback.c:1870<br /> wb_writeback+0x2c5/0xd70 fs/fs-writeback.c:2044<br /> wb_do_writeback fs/fs-writeback.c:2187 [inline]<br /> wb_workfn+0x2dc/0x12f0 fs/fs-writeback.c:2227<br /> process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e4/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> The root cause is that we forgot to do sanity check on .i_extra_isize<br /> in below path, result in accessing invalid address later, fix it.<br /> - gc_data_segment<br /> - is_alive<br /> - data_blkaddr<br /> - offset_in_addr

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads<br /> <br /> This patch fixes slab-out-of-bounds reads in brcmfmac that occur in<br /> brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count<br /> value of channel specifications provided by the device is greater than<br /> the length of &amp;#39;list-&gt;element[]&amp;#39;, decided by the size of the &amp;#39;list&amp;#39;<br /> allocated with kzalloc(). The patch adds checks that make the functions<br /> free the buffer and return -EINVAL if that is the case. Note that the<br /> negative return is handled by the caller, brcmf_setup_wiphybands() or<br /> brcmf_cfg80211_attach().<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> Crash Report from brcmf_construct_chaninfo():<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430<br /> Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896<br /> <br /> CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> dump_stack_lvl+0x57/0x7d<br /> print_address_description.constprop.0.cold+0x93/0x334<br /> kasan_report.cold+0x83/0xdf<br /> brcmf_setup_wiphybands+0x1238/0x1430<br /> brcmf_cfg80211_attach+0x2118/0x3fd0<br /> brcmf_attach+0x389/0xd40<br /> brcmf_usb_probe+0x12de/0x1690<br /> usb_probe_interface+0x25f/0x710<br /> really_probe+0x1be/0xa90<br /> __driver_probe_device+0x2ab/0x460<br /> driver_probe_device+0x49/0x120<br /> __device_attach_driver+0x18a/0x250<br /> bus_for_each_drv+0x123/0x1a0<br /> __device_attach+0x207/0x330<br /> bus_probe_device+0x1a2/0x260<br /> device_add+0xa61/0x1ce0<br /> usb_set_configuration+0x984/0x1770<br /> usb_generic_driver_probe+0x69/0x90<br /> usb_probe_device+0x9c/0x220<br /> really_probe+0x1be/0xa90<br /> __driver_probe_device+0x2ab/0x460<br /> driver_probe_device+0x49/0x120<br /> __device_attach_driver+0x18a/0x250<br /> bus_for_each_drv+0x123/0x1a0<br /> __device_attach+0x207/0x330<br /> bus_probe_device+0x1a2/0x260<br /> device_add+0xa61/0x1ce0<br /> usb_new_device.cold+0x463/0xf66<br /> hub_event+0x10d5/0x3330<br /> process_one_work+0x873/0x13e0<br /> worker_thread+0x8b/0xd10<br /> kthread+0x379/0x450<br /> ret_from_fork+0x1f/0x30<br /> <br /> Allocated by task 1896:<br /> kasan_save_stack+0x1b/0x40<br /> __kasan_kmalloc+0x7c/0x90<br /> kmem_cache_alloc_trace+0x19e/0x330<br /> brcmf_setup_wiphybands+0x290/0x1430<br /> brcmf_cfg80211_attach+0x2118/0x3fd0<br /> brcmf_attach+0x389/0xd40<br /> brcmf_usb_probe+0x12de/0x1690<br /> usb_probe_interface+0x25f/0x710<br /> really_probe+0x1be/0xa90<br /> __driver_probe_device+0x2ab/0x460<br /> driver_probe_device+0x49/0x120<br /> __device_attach_driver+0x18a/0x250<br /> bus_for_each_drv+0x123/0x1a0<br /> __device_attach+0x207/0x330<br /> bus_probe_device+0x1a2/0x260<br /> device_add+0xa61/0x1ce0<br /> usb_set_configuration+0x984/0x1770<br /> usb_generic_driver_probe+0x69/0x90<br /> usb_probe_device+0x9c/0x220<br /> really_probe+0x1be/0xa90<br /> __driver_probe_device+0x2ab/0x460<br /> driver_probe_device+0x49/0x120<br /> __device_attach_driver+0x18a/0x250<br /> bus_for_each_drv+0x123/0x1a0<br /> __device_attach+0x207/0x330<br /> bus_probe_device+0x1a2/0x260<br /> device_add+0xa61/0x1ce0<br /> usb_new_device.cold+0x463/0xf66<br /> hub_event+0x10d5/0x3330<br /> process_one_work+0x873/0x13e0<br /> worker_thread+0x8b/0xd10<br /> kthread+0x379/0x450<br /> ret_from_fork+0x1f/0x30<br /> <br /> The buggy address belongs to the object at ffff888115f24000<br /> which belongs to the cache kmalloc-2k of size 2048<br /> The buggy address is located 1536 bytes inside of<br /> 2048-byte region [ffff888115f24000, ffff888115f24800)<br /> <br /> Memory state around the buggy address:<br /> ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ^<br /> ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ==================================================================<br /> <br /> Crash Report from brcmf_enable_bw40_2g():<br /> ==========<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: smscufx: fix error handling code in ufx_usb_probe<br /> <br /> The current error handling code in ufx_usb_probe have many unmatching<br /> issues, e.g., missing ufx_free_usb_list, destroy_modedb label should<br /> only include framebuffer_release, fb_dealloc_cmap only matches<br /> fb_alloc_cmap.<br /> <br /> My local syzkaller reports a memory leak bug:<br /> <br /> memory leak in ufx_usb_probe<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88802f879580 (size 128):<br /> comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s)<br /> hex dump (first 32 bytes):<br /> 80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|.............<br /> 00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045<br /> [] kmalloc include/linux/slab.h:553 [inline]<br /> [] kzalloc include/linux/slab.h:689 [inline]<br /> [] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline]<br /> [] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655<br /> [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396<br /> [] call_driver_probe drivers/base/dd.c:560 [inline]<br /> [] really_probe+0x12d/0x390 drivers/base/dd.c:639<br /> [] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778<br /> [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808<br /> [] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936<br /> [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427<br /> [] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008<br /> [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487<br /> [] device_add+0x642/0xdc0 drivers/base/core.c:3517<br /> [] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170<br /> [] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238<br /> [] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293<br /> [] call_driver_probe drivers/base/dd.c:560 [inline]<br /> [] really_probe+0x12d/0x390 drivers/base/dd.c:639<br /> [] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778<br /> <br /> Fix this bug by rewriting the error handling code in ufx_usb_probe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: initialize locks earlier in f2fs_fill_super()<br /> <br /> syzbot is reporting lockdep warning at f2fs_handle_error() [1], for<br /> spin_lock(&amp;sbi-&gt;error_lock) is called before spin_lock_init() is called.<br /> For safe locking in error handling, move initialization of locks (and<br /> obvious structures) in f2fs_fill_super() to immediately after memory<br /> allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: Use "buf" flexible array for memcpy() destination<br /> <br /> The "buf" flexible array needs to be the memcpy() destination to avoid<br /> false positive run-time warning from the recent FORTIFY_SOURCE<br /> hardening:<br /> <br /> memcpy: detected field-spanning write (size 93) of single field "&amp;fh-&gt;fb"<br /> at fs/overlayfs/export.c:799 (size 21)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: fix errant WARN_ON_ONCE in j1939_session_deactivate<br /> <br /> The conclusion "j1939_session_deactivate() should be called with a<br /> session ref-count of at least 2" is incorrect. In some concurrent<br /> scenarios, j1939_session_deactivate can be called with the session<br /> ref-count less than 2. But there is not any problem because it<br /> will check the session active state before session putting in<br /> j1939_session_deactivate_locked().<br /> <br /> Here is the concurrent scenario of the problem reported by syzbot<br /> and my reproduction log.<br /> <br /> cpu0 cpu1<br /> j1939_xtp_rx_eoma<br /> j1939_xtp_rx_abort_one<br /> j1939_session_get_by_addr [kref == 2]<br /> j1939_session_get_by_addr [kref == 3]<br /> j1939_session_deactivate [kref == 2]<br /> j1939_session_put [kref == 1]<br /> j1939_session_completed<br /> j1939_session_deactivate<br /> WARN_ON_ONCE(kref

A vulnerability, which was classified as problematic, has been found in elunez eladmin up to 2.7. Affected by this issue is the function checkFile of the file /api/deploy/upload. The manipulation of the argument servers leads to deserialization. The attack may be launched remotely.