Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf trace: Really free the evsel-&gt;priv area<br /> <br /> In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in<br /> evsel-&gt;priv") it only was freeing if strcmp(evsel-&gt;tp_format-&gt;system,<br /> "syscalls") returned zero, while the corresponding initialization of<br /> evsel-&gt;priv was being performed if it was _not_ zero, i.e. if the tp<br /> system wasn&amp;#39;t &amp;#39;syscalls&amp;#39;.<br /> <br /> Just stop looking for that and free it if evsel-&gt;priv was set, which<br /> should be equivalent.<br /> <br /> Also use the pre-existing evsel_trace__delete() function.<br /> <br /> This resolves these leaks, detected with:<br /> <br /> $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin<br /> <br /> =================================================================<br /> ==481565==ERROR: LeakSanitizer: detected memory leaks<br /> <br /> Direct leak of 40 byte(s) in 1 object(s) allocated from:<br /> #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)<br /> #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)<br /> #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307<br /> #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333<br /> #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458<br /> #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480<br /> #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212<br /> #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891<br /> #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156<br /> #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323<br /> #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377<br /> #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421<br /> #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537<br /> #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)<br /> <br /> Direct leak of 40 byte(s) in 1 object(s) allocated from:<br /> #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)<br /> #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)<br /> #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307<br /> #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333<br /> #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458<br /> #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480<br /> #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205<br /> #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891<br /> #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156<br /> #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323<br /> #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377<br /> #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421<br /> #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537<br /> #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)<br /> <br /> SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).<br /> [root@quaco ~]#<br /> <br /> With this we plug all leaks with "perf trace sleep 1".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()<br /> <br /> If &amp;#39;mipid_detect()&amp;#39; fails, we must free &amp;#39;md&amp;#39; to avoid a memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa: Add features attr to vdpa_nl_policy for nlattr length check<br /> <br /> The vdpa_nl_policy structure is used to validate the nlattr when parsing<br /> the incoming nlmsg. It will ensure the attribute being described produces<br /> a valid nlattr pointer in info-&gt;attrs before entering into each handler<br /> in vdpa_nl_ops.<br /> <br /> That is to say, the missing part in vdpa_nl_policy may lead to illegal<br /> nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.<br /> <br /> This patch adds the missing nla_policy for vdpa features attr to avoid<br /> such bugs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: amphion: fix REVERSE_INULL issues reported by coverity<br /> <br /> null-checking of a pointor is suggested before dereferencing it

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Add validation before accessing cgx and lmac<br /> <br /> with the addition of new MAC blocks like CN10K RPM and CN10KB<br /> RPM_USX, LMACs are noncontiguous and CGX blocks are also<br /> noncontiguous. But during RVU driver initialization, the driver<br /> is assuming they are contiguous and trying to access<br /> cgx or lmac with their id which is resulting in kernel panic.<br /> <br /> This patch fixes the issue by adding proper checks.<br /> <br /> [ 23.219150] pc : cgx_lmac_read+0x38/0x70<br /> [ 23.219154] lr : rvu_program_channels+0x3f0/0x498<br /> [ 23.223852] sp : ffff000100d6fc80<br /> [ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:<br /> 000000000000005a<br /> [ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:<br /> fffffffffff0f000

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/perf: add sentinel to xehp_oa_b_counters<br /> <br /> Arrays passed to reg_in_range_table should end with empty record.<br /> <br /> The patch solves KASAN detected bug with signature:<br /> BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]<br /> Read of size 4 at addr ffffffffa1555d90 by task perf/1518<br /> <br /> CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1<br /> Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023<br /> Call Trace:<br /> <br /> ...<br /> xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]<br /> <br /> (cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: exc3000 - properly stop timer on shutdown<br /> <br /> We need to stop the timer on driver unbind or probe failures, otherwise<br /> we get UAF/Oops.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: reduce WARN to dev_dbg() in callback<br /> <br /> The warn is triggered on a known race condition, documented in the code above<br /> the test, that is correctly handled. Using WARN() hinders automated testing.<br /> Reducing severity.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: fix memory leak of remain_skbs<br /> <br /> hif_dev-&gt;remain_skb is allocated and used exclusively in<br /> ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is<br /> processed and subsequently freed (in error paths) only during the next<br /> call of ath9k_hif_usb_rx_stream().<br /> <br /> So, if the urbs are deallocated between those two calls due to the device<br /> deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()<br /> is not called next time and the allocated remain_skb is leaked. Our local<br /> Syzkaller instance was able to trigger that.<br /> <br /> remain_skb makes sense when receiving two consecutive urbs which are<br /> logically linked together, i.e. a specific data field from the first skb<br /> indicates a cached skb to be allocated, memcpy&amp;#39;d with some data and<br /> subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs<br /> deallocation supposedly makes that link irrelevant so we need to free the<br /> cached skb in those cases.<br /> <br /> Fix the leak by introducing a function to explicitly free remain_skb (if<br /> it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL<br /> when it has not been allocated at all (hif_dev struct is kzalloced) or<br /> when it has been processed in next call to ath9k_hif_usb_rx_stream().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: fix clear_user_rep_good() exception handling annotation<br /> <br /> This code no longer exists in mainline, because it was removed in<br /> commit d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory<br /> clearing") upstream.<br /> <br /> However, rather than backport the full range of x86 memory clearing and<br /> copying cleanups, fix the exception table annotation placement for the<br /> final &amp;#39;rep movsb&amp;#39; in clear_user_rep_good(): rather than pointing at the<br /> actual instruction that did the user space access, it pointed to the<br /> register move just before it.<br /> <br /> That made sense from a code flow standpoint, but not from an actual<br /> usage standpoint: it means that if user access takes an exception, the<br /> exception handler won&amp;#39;t actually find the instruction in the exception<br /> tables.<br /> <br /> As a result, rather than fixing it up and returning -EFAULT, it would<br /> then turn it into a kernel oops report instead, something like:<br /> <br /> BUG: unable to handle page fault for address: 0000000020081000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> ...<br /> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147<br /> ...<br /> Call Trace:<br /> __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]<br /> clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]<br /> iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800<br /> iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]<br /> iomap_dio_iter fs/iomap/direct-io.c:440 [inline]<br /> __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601<br /> iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689<br /> ext4_dio_read_iter fs/ext4/file.c:94 [inline]<br /> ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145<br /> call_read_iter include/linux/fs.h:2183 [inline]<br /> do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733<br /> do_iter_read+0x2f2/0x750 fs/read_write.c:796<br /> vfs_readv+0xe5/0x150 fs/read_write.c:916<br /> do_preadv+0x1b6/0x270 fs/read_write.c:1008<br /> __do_sys_preadv2 fs/read_write.c:1070 [inline]<br /> __se_sys_preadv2 fs/read_write.c:1061 [inline]<br /> __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> which then looks like a filesystem bug rather than the incorrect<br /> exception annotation that it is.<br /> <br /> [ The alternative to this one-liner fix is to take the upstream series<br /> that cleans this all up:<br /> <br /> 68674f94ffc9 ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory copies")<br /> 20f3337d350c ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory clearing")<br /> adfcf4231b8c ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory copies")<br /> * d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory clearing")<br /> 3639a535587d ("x86: move stac/clac from user copy routines into callers")<br /> 577e6a7fd50d ("x86: inline the &amp;#39;rep movs&amp;#39; in user copies for the FSRM case")<br /> 8c9b6a88b7e2 ("x86: improve on the non-rep &amp;#39;clear_user&amp;#39; function")<br /> 427fda2c8a49 ("x86: improve on the non-rep &amp;#39;copy_user&amp;#39; function")<br /> * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM")<br /> e1f2750edc4a ("x86: remove &amp;#39;zerorest&amp;#39; argument from __copy_user_nocache()")<br /> 034ff37d3407 ("x86: rewrite &amp;#39;__copy_user_nocache&amp;#39; function")<br /> <br /> with either the whole series or at a minimum the two marked commits<br /> being needed to fix this issue ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: radio-shark: Add endpoint checks<br /> <br /> The syzbot fuzzer was able to provoke a WARNING from the radio-shark2<br /> driver:<br /> <br /> ------------[ cut here ]------------<br /> usb 1-1: BOGUS urb xfer, pipe 1 != type 3<br /> WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504<br /> Modules linked in:<br /> CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504<br /> Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7<br /> RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000<br /> RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac<br /> RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001<br /> R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200<br /> FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58<br /> usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387<br /> shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88<br /> ...<br /> <br /> The problem was caused by the fact that the driver does not check<br /> whether the endpoints it uses are actually present and have the<br /> appropriate types. This can be fixed by adding a simple check of<br /> these endpoints (and similarly for the radio-shark driver).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeon_ep: cancel queued works in probe error path<br /> <br /> If it fails to get the devices&amp;#39;s MAC address, octep_probe exits while<br /> leaving the delayed work intr_poll_task queued. When the work later<br /> runs, it&amp;#39;s a use after free.<br /> <br /> Move the cancelation of intr_poll_task from octep_remove into<br /> octep_device_cleanup. This does not change anything in the octep_remove<br /> flow, but octep_device_cleanup is called also in the octep_probe error<br /> path, where the cancelation is needed.<br /> <br /> Note that the cancelation of ctrl_mbox_task has to follow<br /> intr_poll_task&amp;#39;s, because the ctrl_mbox_task may be queued by<br /> intr_poll_task.